[POLL] Configuration API of tomcat5

[Costin Manolache <cm...@yahoo.com>]

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

Costin






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [POLL] Configuration API of tomcat5

[Costin Manolache <cm...@yahoo.com>]

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. 


Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [POLL] Configuration API of tomcat5

[Remy Maucherat <re...@apache.org>]

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.

Maybe.

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

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>