A couple of testsuite questions

[davidjencks]

1. ...jmx/test/ServiceDeployerUnitTestCase null info test. This test attempts to deploy a dynamic mbean that has null mbean info. The RI registers it but throws an exception when you ask for the mbean info. JBossMX appears to register the mbean and return null when you ask for the mbean info. Is this correct behavior? (Currently the ServiceConfigurator checks for null mbean info).

2. ...jmx/test/MBeanClassLoaderUnitTestCase. I thought jbossmx was supposed to have fixed the situation tested for in this test, it has always failed with the RI. Could someone familiar with jbossmx classloading take a look at this and see if the test is wrong?

Thanks
david jencks

[juha]

> 1. ...jmx/test/ServiceDeployerUnitTestCase null info test. This test attempts to deploy a dynamic mbean
> that has null mbean info. The RI registers it but throws an exception when you ask for the mbean info.
> JBossMX appears to register the mbean and return null when you ask for the mbean info. Is this
> correct behavior? (Currently the ServiceConfigurator checks for null mbean info).

I think we should check for null info at registration and throw an exception if not a valid MBeanInfo exist at that time. Anyone disagree?

> 2. ...jmx/test/MBeanClassLoaderUnitTestCase. I
> thought jbossmx was supposed to have fixed the
> situation tested for in this test, it has always
> failed with the RI. Could someone familiar with
> jbossmx classloading take a look at this and see if
> the test is wrong?

I tracked the code to JBossTestCase to JBossTestServices where it does a remote invocation to "deploy" operation at which point a stopped tracking it.... what is the test trying to test and why are you expecting to get the same cl back? (who is your cl, an mlet?)

-- Juha

[adrian.brock]

1. ServiceDeployerUnitTestCase
The spec doesn't say very much about this, except that
the MBeanInfo is not validated at registration.

The javadocs allow for three errors
IntrospectionException - for StandardMBeans
InstanceNotFoundException - when the bean has gone
ReflectionException - to wrap errors thrown by the Dynamic MBean

2. MBeanClassLoaderUnitTestCase
I'm not sure whether this can be made to work.
The MBeanClassLoader delegates to the UnifiedClassLoader,
through the ServiceLibraries.
The class reports the UnifiedClassLoader as its
classloader.
Isn't the point of the unified classloading to avoid
marshalling objects where the same class gets loaded from
different classloaders?

Regards,
Adrian

[davidjencks]

> 1. ServiceDeployerUnitTestCase
> The spec doesn't say very much about this, except
> that
> the MBeanInfo is not validated at registration.
>
> The javadocs allow for three errors
> IntrospectionException - for StandardMBeans
> InstanceNotFoundException - when the bean has gone
> ReflectionException - to wrap errors thrown by the
> Dynamic MBean

It looks like you are saying that getting a null info object back might be spec compliant? If so the test is wrong, the code in ServiceConfigurator is correct.
>
> 2. MBeanClassLoaderUnitTestCase
> I'm not sure whether this can be made to work.
> The MBeanClassLoader delegates to the
> UnifiedClassLoader,
> through the ServiceLibraries.
> The class reports the UnifiedClassLoader as its
> classloader.
> Isn't the point of the unified classloading to avoid
> marshalling objects where the same class gets loaded
> from
> different classloaders?

OK, things have changed since I wrote the test and it should be removed. When I wrote it we got an MBeanClassloader back, but it didnt' change upon redeploy of the ejb -- so you couldn't redeploy with a changed class. Sounds like this is fixed now.

david jencks
>
> Regards,
> Adrian