Costin Manolache wrote:
The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) - using the property changed events - by wrapping each mbean when it is registered.
One important question is if we need to save server.xml, or
just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings.
Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx.
So after thinking about it quite a bit this evening, I'm leaning towards DOM + using the property changed events. Obviously this will add a bit to the development time (good thing I didn't propose any release plan yet), as a replacement for digester is needed, the serializer (Xerces used to have one we could steal) as well, and the logic to keep the DOM tree and the Catalina objects in sync.
We still have the problem of getting changes from JMX ( made via console ) into the config. Property change events are ok, but it means all
plugins will be required to support them.
To be honest, I was hoping server.xml will disapear. Tomcat is now very JMX based, it is easily integrable into a lot of apps, it is used in large sites. I don't think server.xml is the right choice for long term.
What we need IMO is to separate the setting storage ( including updates). If tomcat is embedded in jboss, it should use jboss config style. It should also be able to use LDAP, NDS, win registry ( via java.prefs ) or any other config storage.
All we really need is a list of mbeans and some attributes for each.
Costin
Thanks for the comments from everyone about various technologies, but the big problem right now is that the save-to-xml really messes up the XML configuration,so that people won't want to edit it manually ever again once they start using the admin webapp (and then we know what happens, there's a limitation/bug in the tool, and the user is stuck - it's the M$ syndrome). DOM seems the only thing which keeps everything (of course, it's the reason why it's slow, bloated and everyone hates it ;) ).
I'll keep on using the repackaged digester for web.xml parsing unless someone has a better idea.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
