XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

For Luca's tightly coupled session use case, I can't tell if it's a  
good idea to store or cache XOM documents. But if it is, and  
performance/size really matters, I'd certainly use the Nux  
BinaryXMLCodec for this and/or the Nux DocumentPool (a very efficient  
main memory cache for XOM documents). These are designed for  
precisely such purposes, and are many times more efficient than plain  
XML [de]serialization (or indeed Java object [de]serialization).

Wolfgang.



> This need not be the case at all. You basically need an application  
> layer between the servlet API and the XOM API, rather than just  
> putting the raw XOM objects in the servlet session.
>
> I came up with three simple approaches appropriate based on what's  
> been in the thread so far (you seem to indicate that you don't need  
> the objects to be restored, ie: you are using the servlet session  
> as convenience cache - a solution that doesn't scale well with  
> complexity, try EHCache among many if you outgrow the session):
>
> a) Wrap the XOM objects when you put them in the session
>
> This is something like:
>
> public class XOMSnippetWrapper implements Serializable {
>     transient private Element element;  // plus accessors
> }
>
> You don't pay either the explicit XOM cost or the implicit servlet  
> cost. The big problem here is that the entry remains in the session  
> when/if you restore the session.
>
> b) A better variant to address that addresses restored sessions at  
> the cost of a little more code is to wrap the collection of  
> snippets and store the container (a little more work makes this  
> restorable as well, with XML as the serialization format):
>
> public class XOMSnippets implements Serializable {
>     private transient Map = new HashMap(); // an empty, fresh one  
> is created on restore
>     public Element get(Object key) { ... }
> }
>
> c) Implement HttpSessionActivationListener for the webapp and throw  
> away (or store as XML) XOM objects in the session before they get  
> serialized.
>
> Putting two fairly low-level API's in direct contact without any  
> application code between them is never a good idea, as you leave  
> yourself without any way to address an "impedance mismatch" between  
> the API's.
>
> Michael Abato
>
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest