Maybe I'm on the wrong track, but there are currently 2 modules (agents | pull-agent) containing 3 individual test cases (Derby, HSQLDB, postgresql). In maven I run the test for the agents module and I thought I would end up with 3 "Configuration file successfully read" messages, because each Test would like to create its own properties files. So, for building the framework with ant I supposed ending up with 6 "Configuration file successfully read" messages.
Let's take as example the org.apache.manifoldcf.agents.tests.SanityPostgresqlTest of the agents module. On the localSetUp method of the parent class (org.apache.manifoldcf.core.tests.BasePostgresql) is org.apache.manifoldcf.core.database.DBInterfacePostgreSQL as database implementation class defined. I supposed to see this class name as implementationClass output in my previous message. Tobias On Mon, Jul 18, 2011 at 3:22 PM, Karl Wright <[email protected]> wrote: > Each time you see "Configuration file successfully read" it indicates > that isInitialized must have been false. Since there is more than one > of these it is clear that in ant you are getting two process > initializations. This makes perfect sense in that two tests are being > invoked. So the process model is working as expected under ant. > > Do you mind telling us what "side effects" are you seeing? > > Karl > > > On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner <[email protected]> wrote: > > I rerun the tests with ant and ended up with the same side effects. > > I did a svn update and added some logging information to the framework. > > Now I'm logging the database implemention class (DBInterfaceFactory - > > make()) and the initialization status on the Manifold class > > (initializeEnvironment()). > > I started the ant build from the mcf root directory with the following > > command: > > "ant clean build run-tests-framework" > > > > > > run-tests: > > [mkdir] Created dir: > > /home/tobr/dev/workspace/apache-mcf/framework/test-output > > [junit] Configuration file successfully read > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] isInitialized: true > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] isInitialized: true > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] Configuration file successfully read > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] isInitialized: true > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] isInitialized: true > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] isInitialized: true > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > [junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > > > BUILD SUCCESSFUL > > > > > > > > > > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright <[email protected]> wrote: > > > >> Looking at this a little more, the proper cleanup of a ManifoldCF > >> process requires that the shutdown thread be run. This thread is > >> added as a shutdown hook to the JVM. The "alreadyClosed" flag is used > >> to prevent it from being run more than once if more than one shutdown > >> signal is received, since it's also executed during object > >> finalization (so that we catch termination within Tomcat and other > >> application servers). > >> > >> So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed > >> perform this coordinated dance on a per-JVM basis. ManifoldCF system > >> initialization is meant to occur once per JVM. Without starting and > >> stopping a JVM, it's therefore not a realistic test. Is there any way > >> for Maven to run each test class in its own JVM, or does it insist on > >> running them all within one? > >> > >> If there is no such possibility, we can look to adding a manual > >> shutdown thread invocation in a reset method. There are lots of > >> potential problems with this approach in that dangling temporary > >> threads that are waiting forever on sockets etc might be left around > >> from previous tests, and other JVM static state such as the cache > >> might also not get cleared, but the tests would probably execute > >> nonetheless. > >> > >> Karl > >> > >> > >> On Mon, Jul 18, 2011 at 8:26 AM, Karl Wright <[email protected]> > wrote: > >> > I think the likely difference is that ant is running each test in its > >> > own JVM, and Maven is not. > >> > > >> > Now, it is straightforward enough to add functionality that resets the > >> > ManifoldCF core classes, and tie that into the tests. However, that > >> > is not how ManifoldCF will be used in practice. The concern I have is > >> > that there are other static variables (for instance, the cache > >> > manager) which are never "reset", but would be if we need to "start > >> > from scratch" again inside the same JVM every time a test is run. > >> > Identifying all such cases may take some time. > >> > > >> > Karl > >> > > >> > > >> > On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright <[email protected]> > wrote: > >> >> These tests run fine under ant, but the ant build invokes test files > >> >> explicitly. I'm not quite sure what Ant's behavior is here, and how > >> >> exactly it differs from Maven's. > >> >> > >> >> Karl > >> >> > >> >> On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner <[email protected]> wrote: > >> >>> The unit tests are currently not working. > >> >>> The first test in a module creates the properties and logging files > and > >> >>> initializes the framework. > >> >>> All following tests are also creating those files, but because the > >> framework > >> >>> is already initialized, they are useless. > >> >>> > >> >>> This depends on the static behaviour of ManifoldCF.isInitialized. > >> >>> After a test is done the ManifoldCF Object should also be reseted. > >> >>> > >> >> > >> > > >> > > >
