3 Replies Latest reply on Mar 24, 2002 9:00 PM by David Jencks

    A couple of testsuite questions

    David Jencks Master

      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

        • 1. Re: A couple of testsuite questions
          Juha Lindfors Master

          > 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

          • 2. Re: A couple of testsuite questions
            Adrian Brock Master

            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

            • 3. Re: A couple of testsuite questions
              David Jencks Master

              > 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