XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

Add clarity of API, correctness of XML implementation, and performance
to the list of reasons to use XOM. And use it in EJB. But keep in mind that
XOM is itself functions as a persistence mechanism and to expect it to
implement Serializable is analogous to expecting a JDBC result object to
be Serializable, which I can't imagine being seriously entertained. That 
implementing Serializable in XOM would be a doable task is beside the point.

As was been pointed long ago, if you need to persist a XOM structure,
use XML as the format, as that is exactly what it is designed for. This
can be done in EJB as easily as in any other environment - I detailed two
approaches to doing just that. What's lost is the EJB persistent "magic"
with seemingly zero overhead.

Michael Abato

-----Original Message-----
From: Sandy Mustard <Sandy.Mustard AT ugsplm.com>
Sent: Feb 4, 2004 10:48 PM
To: xom-interest AT lists.ibiblio.org
Subject: Re: [XOM-interest] Use in EJBs


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
> 

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest