tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject [POLL] Configuration API of tomcat5
Date Fri, 09 Aug 2002 04:04:39 GMT
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.

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.

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 ).


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

View raw message