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