org.opencms.file
Class TestPublishIssues

java.lang.Object
  junit.framework.Assert
      junit.framework.TestCase
          org.opencms.test.OpenCmsTestCase
              org.opencms.file.TestPublishIssues

All Implemented Interfaces:

junit.framework.Test

public class TestPublishIssues
extends OpenCmsTestCase

Comment for TestPermissions.

Nested Class Summary

Nested classes/interfaces inherited from class org.opencms.test.OpenCmsTestCase

OpenCmsTestCase.ConnectionData

Field Summary

Fields inherited from class org.opencms.test.OpenCmsTestCase

ARTICLE_TYPEID, DB_MYSQL, DB_ORACLE, m_additionalConnection, m_configuration, m_currentResourceStrorage, m_defaultConnection, m_defaultTablespace, m_indexTablespace, m_resourceStorages, m_setupConnection, m_tempTablespace

Constructor Summary

TestPublishIssues(String arg0)
Default JUnit constructor.

Method Summary

static junit.framework.Test	suite() Test suite for this test class.
void	testDirectPublishWithSiblings() Tests publish scenario "publish all Siblings".
void	testMultipleProjectCreation() Tests multiple creation of a project with the same name.
void	testMultipleProjectCreationGalore() Tries to create very many projects with the same name.
void	testPublishFolderWithChangedFileFromOtherProject() Tests publishing a deleted folder containing a file that was changed in other project.
void	testPublishFolderWithDeletedFileFromOtherProject() Tests publishing a deleted folder containing a file that was deleted in other project.
void	testPublishFolderWithNewFileFromOtherProject() Tests publishing a deleted folder containing a file that was new created in other project.
void	testPublishScenarioA() Tests publish scenario "A".
void	testPublishScenarioB() Tests publish scenario "B".
void	testPublishScenarioC() Tests publish scenario "C".
void	testPublishScenarioD() Tests publish scenario "D".
void	testPublishScenarioE() Tests publish scenario "E".
void	testPublishScenarioF() Tests publish scenario "F".
void	testPublishScenarioG() Tests publish scenario "G".
void	testPublishScenarioH() Tests publish scenario "H".

Methods inherited from class org.opencms.test.OpenCmsTestCase

addTestDataPath, assertAce, assertAcl, assertAcl, assertContains, assertContainsNot, assertContent, assertDateContent, assertDateContentAfter, assertDateCreated, assertDateCreatedAfter, assertDateExpired, assertDateLastModified, assertDateLastModifiedAfter, assertDateReleased, assertEquals, assertEquals, assertEquals, assertFilter, assertFilter, assertFilter, assertFilter, assertFlags, assertHistory, assertHistoryForRestored, assertIsFolder, assertIsIdentical, assertIsNotIdentical, assertLock, assertLock, assertLock, assertModifiedInCurrentProject, assertPermissionString, assertProject, assertPropertyChanged, assertPropertyChanged, assertPropertydefinitionExist, assertPropertydefinitions, assertPropertyEqual, assertPropertyNew, assertPropertyNew, assertPropertyRemoved, assertPropertyRemoved, assertRelation, assertResourceId, assertResourceType, assertSiblingCount, assertSiblingCountIncremented, assertState, assertStructureId, assertType, assertUserCreated, assertUserLastModified, assertVersion, checkErrors, createStorage, deleteFile, echo, generateContent, generateContent, generateName, generateProperties, generateResources, generateSetupTestWrapper, generateUsers, getCmsObject, getConnectionName, getDatabaseProduct, getDbProduct, getPreCalculatedState, getReplacer, getSetupDataPath, getSetupDb, getTestDataPath, importData, importResources, importTestResource, initTestDataPath, removeDatabase, removeDatabase, removeOpenCms, removeStorage, resetMapping, restart, restartOpenCms, setMapping, setupDatabase, setupDatabase, setupOpenCms, setupOpenCms, setupOpenCms, setupOpenCms, setupOpenCms, storeResources, storeResources, switchStorage

Methods inherited from class junit.framework.TestCase

countTestCases, createResult, getName, run, run, runBare, runTest, setName, setUp, tearDown, toString

Methods inherited from class junit.framework.Assert

assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertFalse, assertFalse, assertNotNull, assertNotNull, assertNotSame, assertNotSame, assertNull, assertNull, assertSame, assertSame, assertTrue, assertTrue, fail, fail

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Detail

TestPublishIssues

public TestPublishIssues(String arg0)

Default JUnit constructor.

Parameters:

arg0 - JUnit parameters

Method Detail

suite

public static junit.framework.Test suite()

Test suite for this test class.

Returns:

the test suite

testDirectPublishWithSiblings

public void testDirectPublishWithSiblings()
                                   throws Throwable

Tests publish scenario "publish all Siblings".

This scenario is described as follows: If a direct publish is made, and the option "publish all siblings" is selected, a file that contains siblings will be added multiple times to the publish list, causing a primary key collision in the publish history table.

Throws:

Throwable - if something goes wrong

testMultipleProjectCreation

public void testMultipleProjectCreation()
                                 throws Exception

Tests multiple creation of a project with the same name.

Throws:

Exception - in case the test fails

testMultipleProjectCreationGalore

public void testMultipleProjectCreationGalore()
                                       throws Exception

Tries to create very many projects with the same name.

This displays an issue in the OpenCms v6 project driver, where a project is created with a UNIQUE INDEX based on the given name and the current system time. In rare instances the system time may be identical and an error occurs.

The issue was found in the MySQL project driver, but others DBs may be affected as well.

Throws:

Exception - in case the test fails

testPublishFolderWithChangedFileFromOtherProject

public void testPublishFolderWithChangedFileFromOtherProject()
                                                      throws Throwable

Tests publishing a deleted folder containing a file that was changed in other project.

Throws:

Throwable - if something goes wrong

testPublishFolderWithDeletedFileFromOtherProject

public void testPublishFolderWithDeletedFileFromOtherProject()
                                                      throws Throwable

Tests publishing a deleted folder containing a file that was deleted in other project.

Throws:

Throwable - if something goes wrong

testPublishFolderWithNewFileFromOtherProject

public void testPublishFolderWithNewFileFromOtherProject()
                                                  throws Throwable

Tests publishing a deleted folder containing a file that was new created in other project.

Throws:

Throwable - if something goes wrong

testPublishScenarioA

public void testPublishScenarioA()
                          throws Throwable

Tests publish scenario "A".

This scenario is described as follows: We have users "test1" and "test2". We have two projects, "project1" and "project2". Project "project1" consists of the folder "/". Project "project2" consists of the folder "/folder1/subfolder11/". User "test2" edits the file "/folder1/subfolder11/index.html". After this, user "test1" locks the folder "/folder1" in "project1", and unlocks it again. User "test2" logs in and now publishes "project2".

Wanted result: the changed resource "/folder1/subfolder11/index.html" is published with "project2".

The test illustrates a change in the logic from OpenCms 5 to OpenCms 6: In OpenCms 5, locking a file caused it to switch to the current users project. In OpenCms 6, this is no longer true, at last not if you just lock a parent folder. So in OpenCms 5, this test would fail, since the resource would be in "project1", not "project2".

Throws:

Throwable - if something goes wrong

testPublishScenarioB

public void testPublishScenarioB()
                          throws Throwable

Tests publish scenario "B".

This scenario is described as follows: We have users "test1" and "test2" and projects "projectA" and "projectB". Both projects contain all resources. We have two folders "/foldera/" and "/folderb/". There is a resource "test.txt" that has a sibling in both folders. User "test1" locks folder "/foldera/" and user "test2" locks folder "/folderb". Now both users try to edit the sibling of "test.txt" in their folder.

TODO: How are concurrent file modifications avoided on the sibling?

Throws:

Throwable - if something goes wrong

testPublishScenarioC

public void testPublishScenarioC()
                          throws Throwable

Tests publish scenario "C".

This scenario is described as follows: Direct publishing of folders containing subfolders skips all changed subfolders e.g. direct publish of /folder1/ publishes /folder1/ and /folder1/index.html/, but not /folder1/subfolder11/.

Throws:

Throwable - if something goes wrong

testPublishScenarioD

public void testPublishScenarioD()
                          throws Throwable

Tests publish scenario "D".

This scenario is described as follows: Direct publishing of folders containing subfolders skips all (sibling) resources in subfolders. e.g. direct publish of /folder2/folder1/ publishes /folder2/folder1/ and /folder2/folder1/index.html/, but not /folder2/folder1/subfolder11/index.html.

Throws:

Throwable - if something goes wrong

testPublishScenarioE

public void testPublishScenarioE()
                          throws Throwable

Tests publish scenario "E".

This scenario is described as follows: Deletion of folders containing shared locked siblings, after copying a folder creating siblings into a new folder and publishing.

Throws:

Throwable - if something goes wrong

testPublishScenarioF

public void testPublishScenarioF()
                          throws Throwable

Tests publish scenario "F".

This scenario is described as follows: We have 2 siblings: sibA.txt and sibB.txt We set a shared property and we publish just one sibling let's say sibA.txt. After publishing both siblings should be unchanged

Throws:

Throwable - if something goes wrong

testPublishScenarioG

public void testPublishScenarioG()
                          throws Throwable

Tests publish scenario "G".

This scenario is described as follows: We have 2 siblings: sib1.txt and sib2.txt We do a content modification and we publish just one sibling let's say sib1.txt. After publishing both siblings should be unchanged

Throws:

Throwable - if something goes wrong

testPublishScenarioH

public void testPublishScenarioH()
                          throws Throwable

Tests publish scenario "H".

This scenario is described as follows: We have 2 unchanged siblings: sibX.txt and sibY.txt Now we set a different individual property on each sibling and we publish just one sibling let's say sibX.txt. After publishing only sibX.txt should be unchanged and sibY.txt should still be changed

Throws:

Throwable - if something goes wrong