2 Replies Latest reply on Jan 24, 2003 12:39 PM by Juha Lindfors

    jboss mm jmx without URLClassloader?

    Stefan Newbie


      I'm actually try to port jboss jmx to a embedded device. (www.ibutton.com/tini).
      The tini sdk is different of the j2me specification, but better, eg: supports dynamic classloading.
      The jboss jmx is too big for such a device but it is difficult to make a decision what is necessary and what can be delete from such a jmx for embedded devices.

      I have low experimence with jmx development, so it will be very great if the jmx experts can help me to make a decision.

      So far I simply implement the objects (hashmap, arry etc), the jmx need to run and that are not inside the tini sdk.

      As another example the tini sdk has no URLClassloader, but here I’m not sure I should implement a URLClassloader or better change the jmx classes to use a normal classloader.

      The urlclassloader is only used by the UnifiedClassloader and the Mlet object.

      What would you prefer?

      Thanks for any hints.

        • 1. Re: jboss mm jmx without URLClassloader?
          Adrian Brock Master

          You can ditch the MLet if you haven't got
          a URLClassLoader.
          The only thing you need to implement is
          DefaultLoaderRepository for classloading.

          I started splitting JBossMX a while ago.
          There is a jbossmx-core.jar and
          jbossmx-services.jar ("optional" stuff)
          But I didn't get very far with it, only the
          some javax.management classes. I didn't really
          look at org.jboss.mx

          You can probably reduce the size a lot by removing
          modelmbeans? Although don't try this with the jboss4
          version :-)


          • 2. Re: jboss mm jmx without URLClassloader?
            Juha Lindfors Master

            You could implement your own URL classloader. The MLet implementation that is currently in the MX base is only a implementation of the service. You could fairly easily provide your own similar service implementation that behaves the same but extends YourURLClassloader (plus if you control the URLClassloader implementation you can get some nice management statistics out of it as part of the services management interface as well).