On Thu, 29 Jul 2004 16:55:39 +0200, Remy Maucherat <[EMAIL PROTECTED]> wrote: > 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).
the XStream API is super simple and I think it should be able to restore the object. XStream xstream = new XStream(); String xml = xstream.toXML(myObject); // serialize to XML Object myObject2 = xstream.fromXML(xml); // deserialize from XML the only catch I can see is it doesn't use attributes. In the case of JMeter, mike wrote a simple class to convert jmeter's hashtree to a simpler format. that resulted in smaller files and good performance. > > 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) > you do loose comments with XStream. Not sure how important comments are. XStream is xml from a java perspective, so it's the opposite of DOM in that respect. > 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 > another option might by Jibx, which is also xml from a Java perspective. It's much more flexible and allows for all sorts of mapping/conversion. peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
