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