tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [POLL] Configuration API of tomcat5
Date Fri, 09 Aug 2002 09:24:32 GMT
Costin Manolache wrote:
> Few questions:
> 1. JMX as low-level configuration API. 
> The question is - should we follow the path of JBoss and make everything 
> that is configurable an MBean, and base the entire architecture on JMX ? 
> The benefits:
> - standard API
> - reasonably clean
> - easy to integrate with other apps using JMX
> Possible problems:
> - may affect performance ( lots of introspection - jboss does a lot of 
> tricks in their jmx impl. )
> - we still don't have the test suite for jmx - so licence issues are still
> there ( and we don't know if mx4j would pass it )
> - we'll be very dependent on JMX - with little control over implementation.
> - again, tomcat won't work without jmx.

BTW, I don't see performance being much worse than the current solution, 
which is already very slow, and is also completely based on introspection.

> 2. Wrapper->JMX for configuration. 
> We can use a small wrapper that will work without JMX. Something
> similar with modeler, but with no 'direct' dependency on JMX. We can
> register the components with this wrapper and use it to pass/query config
> info. If JMX is available, that will translate into JMX calls. 
> One possible ( still standard ) API for the wrapper is JNDI. If we 
> register all the 'interesting' objects in the jndi we can easily 
> 'wrap' them for jmx. The APIs are very similar, the code is easy
> and most people are supposed to be familiar with the API. There
> are other choices as well.
> We already depend on JNDI - so no extra deps here, and it'll probably 
> be easier to make it work with ldap or other backends.


> 3. Small config API ( with JMX hooks ). That's what I started in 
> util.config - just minimal objectName/attributes/attriubte change 
> notifications, no extra overhead. 
> That would probably be cleaner and smaller, but it's yet-another-api.

That's up to you. If you think it's useful to use a middle man between 
JMX and the Tomcat code, then I think it's good.

An advantage of that one may be that the (needed) refactoring of the 
config save may actually be clean, and that it abstracts the 
configuration storage (good).

> 4. Just keep the current API and implementation, with a jmx layer on top. 
> The listener provides access to the objects and allows it to transparently
> register them with JMX. We rewrite the config read to keep the information
> in memory and get all the changes made by user, then save. We could use
> DOM or something similar and preserve even the comments ( if XML backend
> is used ). 
> The key difference is in what we use as a low-level API to 'assemble'
> the components. First 3 choices give more decoupling, the third is the
> easiest to implement ( almost nothing to change ).

The 3rd one looks the most interesting. It provides a good level of 
abstraction while being independent from JMX.

I'd be willing to help implement it.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message