So please let me know if I should commit the patch I created which allows tests to run all in the same JVM. It's reasonably harmless (I think), but I'd not want to commit it if it was unnecessary.
Thanks, Karl On Mon, Jul 18, 2011 at 10:26 AM, Tobias Rübner <[email protected]> wrote: > Ahh ok, sorry for that! > I run all the tests of a module at once. That leads to confusing results. > Now I would also structure the tests in maven to run the derby tests per > default. > All other test must be invoked through different profiles. > > Tobias > > > > On Mon, Jul 18, 2011 at 3:58 PM, Karl Wright <[email protected]> wrote: > >> run-tests-framework only invokes the Derby tests. That's why you are >> not seeing any others. >> >> Karl >> >> On Mon, Jul 18, 2011 at 9:50 AM, Tobias Rübner <[email protected]> wrote: >> > 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. >> >> >> >>> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >
