XOM API for Processing XML with Java

[Sandy Mustard <Sandy.Mustard AT ugsplm.com>]

I use XOM because it is easy to program.  I don't see why I can't use it 
in an EJB.  I don't want to have my developers using two different 
methods of accessing XML.

Making XOM serializable can be as simple as adding "implements 
Serializable".

Is there any state information within XOM that would change between the 
time the objects are persisted and then restored?

The EJB persistance mechanism will persist the entire EJB at the 
'ejbPassivate' method and restore the EJB at the 'ejbAtivate' method. 
Between these two calls, there is basically nothing that happens to the 
EJB ands its referenced objects so nothing would change the state of any 
XOM objects.

Serializing an object requires only that it meets one of two criteria. 
The class must either implement the Serializable interface 
(java.io.Serializable) which has no methods that you need to write or 
the class must implement the Externalizable interface which defines two 
methods. As long as you do not have any special requirements, making a 
serializable is as simple as adding the ``implements Serializable'' clause.

Any object that may be subject to serialization must, at a minimum, 
implement the Serializable interface. This interface does not define any 
methods, but rather serves as an indication that the developer of the 
class has considered the effects that serialization would have on the 
object.

The Java Object Serialization Specification is available at: 
http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/serialTOC.doc.html

Sandy Mustard

Michael Abato wrote:

> I suspect that using XOM objects in an EJB is going to lead to exactly the kind of 
> mismatch of persistence techniques that justifies not making XOM persistent-capable in 
> the first place (disclaimer: I'm not EJB wizard either, but I have dealt with this 
> issue). I use XOM transiently to pull data out of the XML persistent stores and 
> populate application-level data structures that are themselves persistent. I found this 
> actually clarifies my application model as a side effect. The application level 
> question about a field that is (was) a XOM Element (for example) boils down to "Is 
> it part of an XML document or an application artifact?" It really can't/shouldn't 
> be both.
>
> Another approach to consider is to use XOM as the serialization format for the whole 
> EJB. This would mean marking most everything transient and working with XOM in the 
> persistence methods - persisting as one big string which happens to be valid XML. You 
> lose the "magic" aspect of EJB serialialization (which I've never been a fan 
> of in the first place...), but gain tremendous control over the persistence process. 
> Any non-trivial code which interacts with complex external resources (like XML files 
> you would likely have read in) has to deal with the murky details of all this, anyway.
>
> Michael Abato
>
> -----Original Message-----
> From: Rich Sezov <sezovr AT yahoo.com>
> Sent: Feb 4, 2004 7:10 AM
> To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
> Cc: xom-interest AT lists.ibiblio.org
> Subject: Re: [XOM-interest] Use in EJBs
>
> --- Elliotte Rusty Harold <elharo AT metalab.unc.edu>
> wrote:
>
>
> > reasonable alternative. For example, is there some
> > reason you can't 
> > implement your own subclasses of the XOM classes
> > that do implement 
> > Serializable? 
>
>
> Yes; I could probably do that. It's a trade-off,
> though. I was recently re-introduced to the
> complexities of using the DOMParser to parse out my
> XML, since I couldn't use XOM to do it in my EJB, so
> the choice is: will it take me longer to subclass all
> the stuff I'm going to use out of XOM, or to rewrite
> my methods using the DOMParser that comes with Xerces?
> Plus, that's sort of a hack, isn't it? 
>
> I'm sort of new to XML parsing in general (and EJBs,
> for that matter--this one is my first), so I can't say
> I've tried all that many things. Maybe this is like
> the blind leading the blind here. :-)  But the
> DOMParser classes must be Serializable (disclaimer: I
> haven't looked at the source) because I can use that
> API just fine in an EJB. 
>
> I agree with you that developers shouldn't abuse the
> Serializable interface by writing out the objects
> themselves to disk, but use in an EJB, I think, is a
> legitimate reason to implement it. 
>
> =====
> Rich Sezov
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest