You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2003/07/05 05:30:50 UTC
XMLBeans performance and source code status [Re: Proposal: XMLBeans]
Cliff Schmidt wrote:
>>What's compelling about XMLBeans compared to some of the other front
>>runners, such as JDOM and XOM, Castor and JAXB?
>>
>>
>
>The main difference between XMLBeans and JDOM or XOM is that XMLBeans
>does not create objects for each XML information item. Instead, it
>provides cursor-based access to each item in the XML Infoset. It has
>an architecture where, if an actual object is needed for a node, it
>can be created on-demand. We found this provided great performance
>benefit.
>
hi,
i am interested to find if you have some more details on performance
benefits - it seems to be very intriguing and distinguishing feature of
XMLBeans.
i may be missing something but i tried to find this information online
without any lack (i checked
http://dev2dev.bea.com/articles/hitesh_seth.jsp that is good overview
but has not enough technical details and other docs): as far as i can
understand actual objects are created for every XML information item? so
as objects are in memory the same way as objects in DOM what performance
benefits do you have in mind? do you refer to faster creation time or
lower memory footprint? did you check for example on the same machine
how big XML document can be loaded with XMLBeans and DOM (for example
Xerces2) before running out of memory?
>The biggest differences between XMLBeans and Castor or JAXB
>are:
>1) the goal of 100% Schema support (currently supports everything in
>Schema other than redefine and substitution groups, and those features
>are nearly ready), and
>2) the integrated and synchronized access of the underlying XML content
>with strongly typed Java classes.
>
did you estimate what is impact of requiring synchronized access? i am
really curious why was is it required:. i can see need to share XML
schemas but why to require synchronizing access to XML content? i would
think that approach from java.util where collections are not thread-safe
until specifically made synchronized could work here as well?
>>I'd say you'd want to do as much setup before incubation as possible.
>>This includes normalizing your code layout (something that didn't
>>materialize for Tapestry, unfortunately) to match the other Jakarta
>>projects (this will ease things if and when you transition to Maven
>>builds). You probably want to check out a bit about Gump as well ...
>>I can think of one person who will probably veto you until you are
>>integrated into Gump. It's *exceptionally* painful to work with Gump
>>at the moment, but ultimately worth it.
>>
>>
i have question concerning Gump bit in general what is on Wiki page
http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansProposal:
(...) '''(2) identify the initial source from which the subproject is to be populated'''
*http://workshop.bea.com/xmlbeans/XsdUpload.jsp
(...)
i looked on source code and it seems that it is not possible to rebuild
xbean.jar just from source and it is not clear what are dependencies?
i noticed there are parts of code that depends on outside packages (like
weblogic.xml.stream.XMLInputStream or com.bea.xquery) and some
subpackages that are in com.bea.xml* that are in xbean.jar but not in
src directory?
what are plans for those pieces of code - are they also open source or
XMLBeans would depend on BEA implementation classes to be on CLASSPATH
to compile it?
i hope XmlBeans will be actively developed as open source (in Apache or
outside) so it continues to grow as it really looks like an interesting
project.
thanks,
alek
--
If everything seems under control, you're just not going fast enough. —Mario Andretti
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org