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

Reply via email to