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]

Reply via email to