Re: [JBoss-dev] jmx unit tests
) [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. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
) [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. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net
RE: [JBoss-dev] jmx unit tests
The 3.2 branch is down to the same failures as head. The issue with the two class loader failures is due to the fact that we don't like anything but UCLs in the ULR and the MLet is transferred into an equivalent UCL on addition, but we lose the mapping between the UCL and MLet and when the MLet is removed we can't find the associated UCL in the ULR. This should be easy to fix by adding a non-UCL to UCL map to the ULR. [java] 3) testMLetLoadClassFromURLInConstructor(test.compliance.loading.MLetTEST) junit.framework.AssertionFailedError: class test.compliance.loading.support.Trivial was still found in CL repository. [java] at test.compliance.loading.MLetTEST.testMLetLoadClassFromURLInConstructor(M LetTEST.java:102) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48) [java] 4) testBasicMLetFileLoad(test.compliance.loading.MLetTEST) junit.framework.AssertionFailedError: class test.compliance.loading.support.Trivial was already found in CL repository. [java] at test.compliance.loading.MLetTEST.testBasicMLetFileLoad(MLetTEST.java:122 ) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48) Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 2:28 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] jmx unit tests JBOSS-HEAD: /cygdrive/d/jboss-head/jmx $ sh build.sh test-compliance-JBossMX Searching for build.xml ... Buildfile: d:\jboss-head\jmx\build.xml ... [java] 1) testNotificationEmitterRemoveTripletFailsOnBroadcaster (test.compliance.server.MBeanServerInvocationHandlerTestCase) junit.framework.AssertionFailedError: removeNotificationListener (NotificationListener, NotificationFilter, Object)should not work for a broadcaster * This is JMX1.2 API, so Adrian will know the details [java] 2) testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST) junit.framework.AssertionFailedError: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor' here -- should be 'operation' * Incorrect metadata value for a model mbean constructor, I vaguely remember 1.2 spec has a different semantic specified here compared to 1.0 [java] 4) testPathological(test.compliance.query.QueryTestCase) junit.framework.AssertionFailedError: FAILS IN JBossMX: expected Hello(?:.) to match Hello(?:.) * IIRC, spec ambiguity, Adrian might remember more on this. I don't think any of the above needs fixing to port changes to jmx layer. The two errors on classloading and one error on classloading in implementation suite however might be worth looking at. -- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 On Tue, 20 Jan 2004, Scott M Stark wrote: What is the status of the unit tests in the jmx module as opposed to the unit tests in testsuite/.../jbossmx? There are more tests in the jmx module, but there are a fair number of errors. The 3.2 branch tests for serialization are totally broken. Are the jmx modules tests being maintained, and what is in the testsuite module vs the jmx module? The serialization tests in the 3.2 branch are totally broken. HEAD: [EMAIL PROTECTED] jmx]$ ant test-compliance-full-JBossMX ... [java] Tests run: 926, Failures: 4, Errors: 2 [EMAIL PROTECTED] jmx]$ ant test-implementation ... [java] Tests run: 67, Failures: 1, Errors: 1 [EMAIL PROTECTED] jmx]$ ant test-serialization-1.0 [java] Serialization Tests: jmx.serial.form=1.0 ... [java] Tests run: 93, Failures: 3, Errors: 16 Branch_3_2: [EMAIL PROTECTED] jmx]$ ant test-compliance-full-JBossMX ... [java] Tests run: 926, Failures: 10, Errors: 2 [EMAIL PROTECTED] jmx]$ ant test-implementation ... [java] Tests run: 67, Failures: 1, Errors: 1 [EMAIL PROTECTED] jmx]$ ant test-serialization-1.0 ... [java] Tests run: 93, Failures: 0, Errors: 73 Scott Stark Chief Technology Officer JBoss Group, LLC --- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
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. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
JBOSS-HEAD: /cygdrive/d/jboss-head/jmx $ sh build.sh test-compliance-JBossMX Searching for build.xml ... Buildfile: d:\jboss-head\jmx\build.xml ... [java] 1) testNotificationEmitterRemoveTripletFailsOnBroadcaster (test.compliance.server.MBeanServerInvocationHandlerTestCase) junit.framework.AssertionFailedError: removeNotificationListener (NotificationListener, NotificationFilter, Object)should not work for a broadcaster * This is JMX1.2 API, so Adrian will know the details [java] 2) testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST) junit.framework.AssertionFailedError: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor' here -- should be 'operation' * Incorrect metadata value for a model mbean constructor, I vaguely remember 1.2 spec has a different semantic specified here compared to 1.0 [java] 4) testPathological(test.compliance.query.QueryTestCase) junit.framework.AssertionFailedError: FAILS IN JBossMX: expected Hello(?:.) to match Hello(?:.) * IIRC, spec ambiguity, Adrian might remember more on this. I don't think any of the above needs fixing to port changes to jmx layer. The two errors on classloading and one error on classloading in implementation suite however might be worth looking at. -- 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. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
] 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. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
