Hi All,
 I am planning to use Castor apis for xml-java translation. Kindly let
me know if there is any disadvantage compared to use with DOM4J.
 For the past few days I have been testing with Castor and its  mapping
facilities etc for converting my serializable objects to xml and so and
so forth...Looks good to me.

Thanks,
rgds,
Balaji

-----Original Message-----
From: James Strachan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 12, 2001 3:54 PM
To: Bill la Forge; Dane Foster; [EMAIL PROTECTED]
Subject: Re: [dom4j-user] Thread safety


Hi Bill

From: "Bill la Forge" <[EMAIL PROTECTED]>
> > So we should make a non-lazy implementation of Element for use in
> > multi-threaded modes. Also a SynchronizedElement would be useful
too.
I'll
> > add these developments to our to do list...
>
> Ouch! This is very good to know. I've just put integration with
Quick's
OCM package on hold until a read-only document can be shared
> across threads. (OCM shares its data model across threads. Its
intended
for both client and server-side data transformations.)

I've just checked into CVS a non-lazy implementation of Element which
should
be fine for sharing read-only documents across threads. It avoids doing
any
lazy creation so should be fine. To create non-lazy implementations of
Element try either setting the following system property:-

    org.dom4j.factory=org.dom4j.util.NonLazyDocumentFactory

or using the following code when parsing documents:-

    SAXReader reader = new SAXReader();
    reader.setDocumentFactory( NonLazyDocumentFactory.getInstance() );
    Document shareableDocument = reader.read( "something.xml" );

Either way this should avoid you putting any work on hold ;-)
The daily build should include these changes now if you don't like to
work
off the latest CVS image. The 0.5 release will happen before the end of
next
week.


I'd like to have a fully SynchronizedElement which would allow XML
documents
to be safely modified concurrently in a multi-threaded application,
though
I'm going to think a bit more before implementing it. Its quite easy for
an
application to just synchronize on (say) the document instance before
modifying it.

I'm deliberating about either having a derivation of NonLazyElement
which
uses synchronized List implementations internally (and probably makes a
few
modification methods synchronized), or using a synchronized facade like
the
Collections.synchronizedList() method uses internally.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user

_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user

Reply via email to