Shapira, Yoav wrote:
Hi,I think it's a start. You identified the downsides well enough, but unfortunately, they're a showstopper for me. Additional tweaks are needed. I see that others suggested other technologies, but we'd have many issues as well (assuming XStream or the others can serialize the Catalina tree to a XML which would be readable, I don't see how it would possibly be able to restore it).
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...
Another recurrent problems:
- None of these things support manual editing of the XML file (well, they do, but any formatting, commets, etc is lost)
- The way stuff is saved is clearly quite bad (save evrything, rather than just what is actually modified on one object)
And this is where I think DOM might not suck after all:
- it's a very good representation of the XML document (unlike all the other "fast" solutions, which usually discard the non meaningful stuff)
- by keeping the elements in memory, and using the ContainerListener stuff that I want to remove, we could update the relevant DOM elements as needed rather than blindly save all the non default properties of every object (which doesn't work well with global config files to set defaults, and as soon as you press save all the defaults appear in every config file)
- when asked, we serialize the DOM trees to files; if the serializer is good enough, we'll end up with the same as the original files, with only the needed modifications
The problems:
- it's slower (I think no, the files we're using are small)
- we would need a DOM Digester to read the internal config (server.xml, all context files), while the usual Digester would handle the (much bigger) standard deployment descriptors with SAX
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
