Hi, I've done a bit of work in this space. One approach that I've seen work with very complex object graphs is: - Have an interface, e.g. XMLRepresentationI, with one method, String toXML(); - Have every object along the graph that needs to be saved implement this interface, e.g. Context, Host, Engine, etc. To save a complete Server, we'd call Server.toXML(). The Server would output its own start tag, then call its children containers, e.g. Engine, etc, and then the Server would output its own close tag. The Host would call toXML on all its Contexts, etc.
The advantages of this approach include simplicity (each toXML method tends to be very simple), ease of debugging, and ease of extension by users who write custom classes. It's also obviously possible to do whatever we want with the Server.toXML() output, including writing it in an i18n stream (a current problem of the admin webapp is recurring issues with i18n and encoding), and conveying it over JMX or SNMP to controlling applications or monitoring dashboards. It's also possible to create something like ReflectionToStringBuilder (see Jakarta Commons-Lang API JavaDocs) to automatically generate these XML Strings. This in a sense is a sort of reverse-Digester. There are alternatives like XMLBeans, XPull, XStream that play in this space also, as others have mentioned. But these are additional dependencies and I'm not in a rush to add those. The downsides of this approach are: - If we add an attribute to something, we need to modify the toXML method. This is mitigated by using a ReflectionToXMLBuilder as I suggest above. - The writing code is all over the Catalina codebase, distributed to each component. Some people would prefer to have the writing code in one place, and I understand that. It's a valid design choice either way IMHO, but the latter can pose access problems (everything written would need to be public, can't be protected, whereas with the toXML approach above we easily write private and protected fields. So there's one idea... Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Remy Maucherat [mailto:[EMAIL PROTECTED] >Sent: Thursday, July 29, 2004 9:57 AM >To: Tomcat Developers List >Subject: [5.next] Refactoring save-to-XML > >Hi, > >I'd like to make this feature less hardcoded (right now, it's ugly ;) ). >A first step would be to extract the code to another helper class, but >that's all I can think of. Does anyone have any ideas ? > >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]
