I took a look at this test: I think i understand the problem now.
Here's an example, it was causing TestReplicationHandler to fail, but
i couldnt find any statics as to why, in any of the ReplicationHandler
classes.
So i added this hack:
// FIXME: Find the static/sysprop/file leakage here.
// If we call Class.forName(ReplicationHandler) here, its
test will later fail
// when run inside the same JVM (-Dtests.threadspercpu=0),
so something is wrong.
if (file.contains("ReplicationHandler"))
continue;
Finally, i figured it out... the problem is that this test initializes
static fields in *test classes too*
So there are all kinds of statics in TestReplicationHandler for example...
Perhaps the test would be less dangerous, if we changed this to:
// don't instantiate test classes
if (file.contains("Test"))
continue;
On Mon, Oct 18, 2010 at 10:13 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> The problem is, that some classes initialize static fields (because
> Class.forName() runs static initializers of classes). And that’s the whole
> problem for some of the classes.
>
> Maybe we should reduce the test only to *some* example classes to test the
> MBean logic, but not iterate all classes!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -----Original Message-----
>> From: Ryan McKinley [mailto:ryan...@gmail.com]
>> Sent: Monday, October 18, 2010 4:00 PM
>> To: dev@lucene.apache.org
>> Subject: Re: SolrInfoMBeanTest
>>
>> I will sheepishly step up and say... um, i wrote that.... a long while
> ago.
>>
>> At the time some of the MInfoBeans returned null, and the we had tests
> that
>> covered most things except these getter. This test (at the time) made
> many of
>> the simple classes have 100% coverage and had no side effects.
>>
>> I don't get why calling Class.forName( xxxxx ) would cause something to
> later
>> fail, but I have not objection to disabling the not very useful test
>>
>> ryan
>>
>>
>>
>> On Sun, Oct 17, 2010 at 3:40 PM, Uwe Schindler <u...@thetaphi.de> wrote:
>> > Haha, maybe we found the "func" issue :-) Really bad test, why does it
>> > need to instantiate. Does loading and inspecting the class is not
>> > enough? Or does it init static props?
>> >
>> > -----
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >> -----Original Message-----
>> >> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
>> >> Seeley
>> >> Sent: Sunday, October 17, 2010 9:35 PM
>> >> To: dev@lucene.apache.org
>> >> Subject: Re: SolrInfoMBeanTest
>> >>
>> >> Ha - going through and instantiating a ton of random classes does
>> >> sound
>> > like a
>> >> good way to screw things up!
>> >>
>> >> +1 to disable.
>> >>
>> >> -Yonik
>> >> http://www.lucidimagination.com
>> >>
>> >>
>> >> On Sun, Oct 17, 2010 at 3:22 PM, Robert Muir <rcm...@gmail.com> wrote:
>> >> > Can we disable this test? I don't understand the purpose of it, and
>> >> > it seems to only cause other tests to fail.
>> >> >
>> >> > For example:
>> >> >
>> >> > [junit] NOTE: all tests run in this JVM:
>> >> > [junit] [SolrInfoMBeanTest, TestGroupingSearch]
>> >> > [junit] ------------- ---------------- ---------------
>> >> > [junit] TEST org.apache.solr.TestGroupingSearch FAILED
>> >> >
>> >> > i already had to hack this test once to prevent
>> >> > TestReplicationHandler from always failing:
>> >> >
>> >> > // FIXME: Find the static/sysprop/file leakage here.
>> >> > // If we call Class.forName(ReplicationHandler) here,
>> >> > its test will later fail
>> >> > // when run inside the same JVM
>> >> > (-Dtests.threadspercpu=0), so something is wrong.
>> >> > if (file.contains("ReplicationHandler"))
>> >> > continue;
>> >> >
>> >> > the test seems really silly, it loads up everything in its
>> >> > classpath and assertNotNull's against toString-type things, with
>> >> > the description of "A simple test used to increase code coverage
>> >> > for some standard things..."
>> >> >
>> >> > -------------------------------------------------------------------
>> >> > -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>> >> > additional commands, e-mail: dev-h...@lucene.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>> >> additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>> > additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
>> commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
