tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [POLL] Configuration API of tomcat5
Date Fri, 09 Aug 2002 14:11:16 GMT
On Fri, 09 Aug 2002 02:24:32 -0700, Remy Maucherat wrote:

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

It's much more than the introspection we do, plus tons of Strings 
( the ObjectName ), tons of other objects.

But it's not the worse option - JBoss proved that JMX can be made
efficient and that the model works well. 

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

We should discuss this one a bit more - it basically means a DirContext
that doubles as MBean. ( JBoss has a ContextMBean that can be used to 
view the jndi objects from the admin interface, that's slightly different ).
If we do that all config information will be accessible in both ways.

The APIs are very similar, except the goal of JNDI is more 'storage' 
( not for java:env, but LDAP and all other ), JMX is more 'runtime data'.
And JNDI is more focused on the hierarchy of the DN, while JMX leaves it
almost unspecified as semantic but is strict on syntax.

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

Well, I can't start much code until I know what people want.
And that involves API in the first place, and data format ( for the
default XML file ). But API is the most important.

It seems either everyone is in vacation or too busy - and this is 
too important an issue to do alone. 

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

That would be great - but first I think we need to find more help in
designing it, at least more feedback on which direction to go.

I love java and OO programming, but sometimes I have a feeling it uses
too many ( and too bloated ) APIs and interfaces, and I don't want to
agravate this :-) That's why I slightly perfer one of the first 2 aproaches. 


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

View raw message