XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

On May 31, 2005, at 9:49 AM, Luca Passani wrote:

> the serialization only happens once in a while under exceptional 
> circumstances (i.e. when the application server is restarted).
>
> The solution you propose would be wasting lots of CPU at each and 
> every HTTP request...

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