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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
