Costin Manolache wrote:
Remy Maucherat wrote:
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.
Ah, ok. I thought you were ok with the DOM/server.xml solution. You mention technical problems, but there are none: container events will also need to be used.
I think a JMX based config file would be more complex than server.xml to manipulate for end users (more verbose, even less error checking, because we won't be able to come up with a DTD or schema even if we wanted to, and finally it doesn't represent the actual server structure). So that's a number of problems as far as I'm concerned.
A resource abstraction is quite complex as well (either it's XML or it's not ;) ), and I'm not going to do it. If you want some scheme where Tomcat gets its XML config files from somewhere on startup, then I'm ok with someone adding that.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
