Hi, I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys the structure of the server's configuration. That's possible to replicate in a JMX- or JBoss-style configuration file, but it tends to look uglier and more verbose IMHO. However, your desired a good long-term goal also, I think.
So for now I like the DOM + PropertyChangeEvent model that Remy has proposed. Especially combined with the increased use of setAllProperties, the configuration will be both less verbose and easier to save/restore. Xerces still provide an XML Serializer, two actually. One is what I think we should use, the DOM Level 3 Standard (meaning there's a shot this thing is portable ;)): http://xml.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSSerializer.html, specified in http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/. But as you see these things are fairly new, and as such might be buggy: http://xml.apache.org/xerces2-j/dom3.html. There's also at least one unimplemented method of the LSSerializer (normalize-characters) but we might not need that one. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache >Sent: Friday, July 30, 2004 2:24 AM >To: [EMAIL PROTECTED] >Subject: Re: [5.next] Refactoring save-to-XML > >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. > >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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
