You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Achim Huegen <ah...@gmx-topmail.de> on 2004/12/30 23:53:27 UTC

JMX design issues

I would like to discuss some technical issues of the jmx implementation:

- In the moment there is a dependency on the MX4J library. It uses an 'apache-style license'
   (http://mx4j.sourceforge.net/docs/ch01s06.html). Is it possible to include mx4j in the
   distribution? Tomcat did it in version 4.
   I can remove the dependency, by copying some code. Any license or copyright issues
   with copy&paste?

- The jmx services and connectors shouldn't be loaded by default. The user should have
   these options:
   - don't load jmx at all
   - load only the core services (MBeansRegistry, MBeanServerFactory, MBeanServer)
     but no connectors
   - additionally load a predefined set of connectors with default settings
     (e.g. a http connector on port 80) for quick start.
   - load the metadata support

   Of course these goals could be reached be making one big descriptor file and letting
   the user load the needed services and mbeans by registering them in a contribution to
   EagerLoad and MBeans.
   Another option would be a separate jar for the jmx code that loads the core services
   by default (via META-INF/hivemodule.xml) when included in the classpath and contains
   some additional module descriptors (one for default connectors, one for metadata support)
   that can be loaded as submodules.
   What do you think about the second option?

- The code is in package org.apache.hivemind.management and it uses a separate source
   path. Is it ok or should it be included in the library path?

Achim Huegen





---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org


Re: JMX design issues

Posted by Eric Yung <er...@jspectrum.com>.
Achim Huegen wrote:

> I would like to discuss some technical issues of the jmx implementation:
>
> - In the moment there is a dependency on the MX4J library. It uses an 
> 'apache-style license'
>   (http://mx4j.sourceforge.net/docs/ch01s06.html). Is it possible to 
> include mx4j in the
>   distribution? Tomcat did it in version 4.
>   I can remove the dependency, by copying some code. Any license or 
> copyright issues
>   with copy&paste?

>
> - The jmx services and connectors shouldn't be loaded by default. The 
> user should have
>   these options:
>   - don't load jmx at all
>   - load only the core services (MBeansRegistry, MBeanServerFactory, 
> MBeanServer)
>     but no connectors
>   - additionally load a predefined set of connectors with default 
> settings
>     (e.g. a http connector on port 80) for quick start.
>   - load the metadata support
>
>   Of course these goals could be reached be making one big descriptor 
> file and letting
>   the user load the needed services and mbeans by registering them in 
> a contribution to
>   EagerLoad and MBeans.
>   Another option would be a separate jar for the jmx code that loads 
> the core services
>   by default (via META-INF/hivemodule.xml) when included in the 
> classpath and contains
>   some additional module descriptors (one for default connectors, one 
> for metadata support)
>   that can be loaded as submodules.
>   What do you think about the second option?

Each of the core services, additional connectors and metadata support 
should be in separated jars. So the user can have options.

>
> - The code is in package org.apache.hivemind.management and it uses a 
> separate source
>   path. Is it ok or should it be included in the library path?
>
> Achim Huegen
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org