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
