You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Tobias Rübner <de...@tobr.eu> on 2011/07/18 13:41:11 UTC
invalid unit tests
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.
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
I've attached a patch which, given the caveats already mentioned,
should allow a single-process model to execute the tests. Please let
me know if it seems to work for you.
Karl
On Mon, Jul 18, 2011 at 8:49 AM, Karl Wright <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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.
>>>>
>>>
>>
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com>
>>> 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 <de...@tobr.eu> 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 <da...@gmail.com>
>>> >> 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 <da...@gmail.com>
>>> >> >> 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 <
>>> daddywri@gmail.com>
>>> >> >> 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 <de...@tobr.eu>
>>> >> 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.
>>> >> >> >> >>>
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >
>>> >>
>>> >
>>>
>>
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com>
>> 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 <de...@tobr.eu> 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 <da...@gmail.com>
>> >> 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 <da...@gmail.com>
>> >> >> 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 <
>> daddywri@gmail.com>
>> >> >> 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 <de...@tobr.eu>
>> >> 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.
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: invalid unit tests
Posted by Tobias Rübner <de...@tobr.eu>.
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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com>
> 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 <de...@tobr.eu> 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 <da...@gmail.com>
> >> 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 <da...@gmail.com>
> >> >> 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 <
> daddywri@gmail.com>
> >> >> 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 <de...@tobr.eu>
> >> 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.
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com>
>> 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 <da...@gmail.com>
>> >> 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 <da...@gmail.com>
>> >> 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 <de...@tobr.eu>
>> 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.
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: invalid unit tests
Posted by Tobias Rübner <de...@tobr.eu>.
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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com>
> 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 <da...@gmail.com>
> >> 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 <da...@gmail.com>
> >> 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 <de...@tobr.eu>
> 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.
> >> >> >>>
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <da...@gmail.com>
>> 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 <da...@gmail.com>
>> 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 <de...@tobr.eu> 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.
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: invalid unit tests
Posted by Tobias Rübner <de...@tobr.eu>.
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 <da...@gmail.com> 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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <da...@gmail.com>
> 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 <da...@gmail.com>
> 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 <de...@tobr.eu> 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.
> >> >>>
> >> >>
> >> >
> >>
> >
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <de...@tobr.eu> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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.
>> >>>
>> >>
>> >
>>
>
Re: invalid unit tests
Posted by Tobias Rübner <de...@tobr.eu>.
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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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.
> >>>
> >>
> >
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <da...@gmail.com> 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 <da...@gmail.com> 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 <de...@tobr.eu> 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.
>>>
>>
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <da...@gmail.com> 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 <de...@tobr.eu> 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.
>>
>
Re: invalid unit tests
Posted by Karl Wright <da...@gmail.com>.
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 <de...@tobr.eu> 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.
>