Here is a patch that fixes the problem a little bit more consistent (as it may also load classes not containing "Test": I changed the directory list for the package and check the file path to contain "build/solr" and not to contain "tests". Then only real core classes but no tests are listed.
This may still be a problem, if there are classes in Solr core, that initialize statics incorrectly, but at least all tests are excluded. I would give it a try! Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Robert Muir [mailto:[email protected]] > Sent: Monday, October 18, 2010 4:25 PM > To: [email protected] > Subject: Re: SolrInfoMBeanTest > > 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 <[email protected]> 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: [email protected] > > > >> -----Original Message----- > >> From: Ryan McKinley [mailto:[email protected]] > >> Sent: Monday, October 18, 2010 4:00 PM > >> To: [email protected] > >> 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 <[email protected]> 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: [email protected] > >> > > >> > > >> >> -----Original Message----- > >> >> From: [email protected] [mailto:[email protected]] On Behalf Of > Yonik > >> >> Seeley > >> >> Sent: Sunday, October 17, 2010 9:35 PM > >> >> To: [email protected] > >> >> 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 <[email protected]> > 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: [email protected] For > >> >> > additional commands, e-mail: [email protected] > >> >> > > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] For > >> >> additional commands, e-mail: [email protected] > >> > > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] For > >> > additional commands, e-mail: [email protected] > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] For additional > >> commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
fix-info-mbean.patch
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
