RE: [JBoss-dev] jmx unit tests

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

First the 3.2 build was incorrect.
Second it wasn't testing against the jmxri 1.2

There were three known compliance issues (none are very important they
are on the edge of the spec or relate to UCL semantics versus the
spec's loader repository semantics).

The new failure looks to be caused by this modification:
http://cvs.sourceforge.net/viewcvs.py/jboss/jmx/src/main/org/jboss/mx/notification/MBeanServerListenerRegistration.java?hideattic=0&only_with_tag=JBoss_4_0_0_DR2

Jeff, do you remember the issue with the modelmbean invoker?
I don't think it should be possible to use
remove(NofificationListener, NotificationFilter, Object) against
a Broadcaster through the MBeanServer since a Broadcaster does not
support this method, you need an Emitter.

The other failures are related to incompatible changes in the descriptor
implemention of the RI for modelmbeans.
The RI also has more failures in the "1.0" seralization scheme
which is optional and it has never done this correctly anyway.

Regards,
Adrian

On Tue, 2004-01-20 at 22:49, Juha Lindfors wrote:
> There's a difference in running the JMX compliance suite between 3.2.3-RC2
> checkout and the current 3.2.4-RC1 checkout (with JMX 1.2 head backport)
> 
> 3.2.3-RC2
> =========
> 
> Administrator@helsinki /cygdrive/d/jboss-323-RC2/jboss-3.2/jmx
> $ sh build.sh test-compliance-JBossMX
> Searching for build.xml ...
> Buildfile: d:\jboss-323-RC2\jboss-3.2\jmx\build.xml
> 
> ...
> 
> 
>      [java] There were 3 failures:
>      [java] 1)
> testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)junit.framework.Asserti
> onFailedError: FAILS IN JBOSSMX: ULR3 loads from TCL, should be DLR
>      [java]     at
> test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav
> a:1014)
>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>      [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at
> test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
>      [java] 2)
> testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST)junit.framework.AssertionFailedErr
> or: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor'
> here -- should be 'operation'
>      [java]     at
> test.compliance.modelmbean.ModelMBeanInfoSupportTEST.testGetDescriptor(ModelMBeanInfoSupportTEST.java
> :177)
>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>      [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at
> test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
>      [java] 3)
> testPathological(test.compliance.query.QueryTestCase)junit.framework.AssertionFailedError:
> FAILS IN JBoss
> MX: expected Hello(?:.) to match Hello(?:.)
>      [java]     at
> test.compliance.query.QueryTestCase.testPathological(QueryTestCase.java:1056)
>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>      [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at
> test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37)
> 
>      [java] FAILURES!!!
>      [java] Tests run: 628,  Failures: 3,  Errors: 0
> 
> 
> BUILD SUCCESSFUL
> Total time: 15 seconds
> 
> 
> 
> 
> 3.2.4-RC1
> =========
> 
> /cygdrive/d/jboss-324-RC1/jmx
> $ ./build.bat test-compliance-JBossMX
> Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger
> test-compliance-JBossMX
> Buildfile: build.xml
> 
> ...
> 
>      [java] There were 2 errors:
>      [java] 1)
> testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)ReflectionException:
> Cl
> ass not found: test.compliance.server.support.AClass
>      [java] Cause: java.lang.ClassNotFoundException:
> test.compliance.server.support.AClass
>      [java]     at
> org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerImpl.java:872)
>      [java]     at
> org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:853)
>      [java]     at
> org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:264)
>      [java]     at
> test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav
> a:833)
>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>      [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at
> test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48)
>      [java] Caused by: java.lang.ClassNotFoundException:
> test.compliance.server.support.AClass
>      [java]     at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
>      [java]     at java.security.AccessController.doPrivileged(Native
> Method)
>      [java]     at
> java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>      [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
>      [java]     at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
>      [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>      [java]     at
> org.jboss.mx.loading.UnifiedLoaderRepository3.loadClass(UnifiedLoaderRepository3.java:574)
>      [java]     at
> javax.management.loading.DefaultLoaderRepository.loadClass(DefaultLoaderRepository.java:74)
>      [java]     at
> org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:830)
>      [java]     ... 22 more
>      [java] 2)
> testMLetLoadClassFromURLInConstructor(test.compliance.loading.MLetTEST)java.lang.ClassNotFoundException:
> test.compliance.loading.support.Trivial
>      [java]     at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
>      [java]     at java.security.AccessController.doPrivileged(Native
> Method)
>      [java]     at
> java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>      [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
>      [java]     at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
>      [java]     at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>      [java]     at
> org.jboss.mx.loading.UnifiedLoaderRepository3.loadClass(UnifiedLoaderRepository3.java:574)
>      [java]     at
> javax.management.loading.DefaultLoaderRepository.loadClass(DefaultLoaderRepository.java:74)
>      [java]     at
> test.compliance.loading.MLetTEST.testMLetLoadClassFromURLInConstructor(MLetTEST.java:91)
>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>      [java]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      [java]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at
> test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48)
>      [java] There were 10 failures:
> 
> 
> 
> 3.2.3-RC2 shows no errors, and one known failure related to classloading:
> FAILS IN JBOSSMX: ULR3 loads from TCL, should be DLR
> 
> Where as 3.2.4-RC1 shows two errors on classloading (same errors as in
> HEAD). It appears that some faulty classloading logic was backported from
> the JMX implementation in HEAD with the 1.2 backport
> 
> -- Juha
> 
> 
> 
> 
> 
> 
> On Tue, 20 Jan 2004, Scott M Stark wrote:
> 
> > What are the other 3 known compliance issues? 3.2 and head should be in
> > synch
> > on class loaders and I need to merge some of the changes made to the jmx
> > layer so I want to get these test working before doing the merge.
> >
> >
> > xxxxxxxxxxxxxxxxxxxxxxxx
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> > xxxxxxxxxxxxxxxxxxxxxxxx
> > -----Original Message-----
> > From: jbo...@li...
> > [mailto:jbo...@li...] On Behalf Of Juha
> > Lindfors
> > Sent: Tuesday, January 20, 2004 10:49 AM
> > To: jbo...@li...
> > Subject: Re: [JBoss-dev] jmx unit tests
> >
> >
> > the jmx module unit tests are the ones we run against, the ones in
> > testsuite were never maintained.
> >
> > At least 3 of the 4 failures on compliance are known issues (and
> > reported as such), I don't know about the JMX 1.2 notification emitter
> > one.
> >
> > The two errors are both related to classloading, at least at some point
> > the loader repository impl. in 3.2 worked correctly with these, whatever
> > the diffs in classloading were were not ported back to head.
> >
> > The error in head implementation tests is new, and looks like is related
> > to classloading again. The failure is a known issue and reported as
> > such.
> >
> > I haven't run the serialization tests, Adrian will know about those.
> >
> > I haven't run these against 3.2 for a long while, the number of failures
> > seems high.
> >
> > Serialization-1.0 full failure seems to indicate it's not running
> > against JMX 1.0
> >
> > -- Juha
> >
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > JBoss-Development mailing list
> > JBo...@li...
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> JBoss-Development mailing list
> JBo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxx 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
xxxxxxxxxxxxxxxxxxxxxxxx 