Oh, and in case it was not obvious, I attached the reset patch. Karl
On Tue, Jul 19, 2011 at 9:16 AM, Karl Wright <[email protected]> wrote: > It looks like when a ticket is closed all the attachments are cleaned > up, so you will need to reattach your newest pom's, svn diff'd against > trunk. > > Karl > > On Tue, Jul 19, 2011 at 9:08 AM, Tobias Rübner <[email protected]> wrote: >> Hi Karl, >> >> running the standard module tests works now fine, but I still have some >> issues with the end-to-end tests. >> The first test completes with no errors, but all other fail (just the derby >> tests) with a database not found error. >> Running them in single mode, they will pass. >> The reason is, that after the first test the database is deleted and the >> other tests do not create a new one. >> So I was looking for your patch, but I can not find it. >> Could you please attach the patch to the corresponding issue >> (CONNECTORS-223) (you also should reopen the issue, because the updated pom >> files are also not available). >> >> Thanks, >> Tobias >> >> >> >> >> On Mon, Jul 18, 2011 at 4:30 PM, Karl Wright <[email protected]> wrote: >> >>> 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. >>> >> >> >> >>> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> >>> >> >> > >>> >> >> >>> >> > >>> >> >>> > >>> >> >
