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. >> >>> >> >> >> > >> >
