Re: [vote] XMLBeans to enter XML incubation [was: Re: Vote for XMLBeansproposal in the XML Project (was RE: Vote for XMLBeans proposal)]
Steven Noels wrote: Dear committers, as outlined in the xml.apache.org charter (section 6.2), and in collaboration with the Incubator (http://cvs.apache.org/viewcvs.cgi/incubator/STATUS?rev=HEAD) Subject to: - relicensing of the XMLBeans codebase using the ASL 1.1 license (http://xml.apache.org/LICENSE) - copyright transfer from BEA to the ASF as described in http://incubator.apache.org/process.html [1] - each initial XMLBeans committer sending in a Contributor's License Agreement (http://incubator.apache.org/forms/ASF_Contributor_License_2_form.pdf) - furthermore, I would strongly suggest the XMLBeans code should only be moved into Apache CVS once the outstanding LGPL BEA-licensed code dependency issues have been resolved. Please cast your vote on the acceptance of the XMLBeans project for incubation in the XML.Apache project: --- vote ballot -- Name: [ ] I agree with and support this proposal (+1) +1 thanks, alek ([EMAIL PROTECTED], PMC memeber of Web Services) -- If everything seems under control, you're just not going fast enough. Mario Andretti - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
David Bau wrote: Adding a few links and other info - Eric Vasilik writes: The synchronization described refers to the fact that one may manipulate the XML via the XmlCursor or the strongly typed XMLBean classes generated from the schema As Eric says, we don't want to confuse the two uses of the word synchronize. But since Aleksander brought it up - here's some information on thread-synchronization too. We examined both with- and without-thread-synchronized access, and found that without-thread-sync, programmers fall into traps like working with XML config files on multiple threads in thread-unsafe ways without without being aware of it. We found that it costs between 1% (strongly-typed access) and 10% (XmlCursor access) to synchronize. So we're currently synchronizing access to the data now, paying for more [app] stability with a little bit of perf. We'd like to provide the option to single-threaded (or savvy) users of not synchronizing to get the 1-10% back. That's future work. hi, did you consider fail quickly approach that is used in Java collections (so for example Iterator can detect if it is used from more than one thread and fails if it happens)? the other possibility would be to allow making some objects (such as configuration) immutable so can be safely shared between multiple threads. As Eric pointed out, the key I think is not in what our current numbers are, but the fact that we've isolated our implementation from our interface so that we have the flexibility of reducing allocations, deferring work, and otherwise improving performance further in the future. Abstracting the primary store behind a cursor rather than a tree of objects with identity gives us some leeway in shuffling our implementation strategy in the future without restructing the APIs. that sounds like very good strategy! however i winder what is really current state. when i looked on source code and i could not see how layering could work (or it working already?): what parts are API a interfaces and how implementation is separated and can be switched - is this possible in current version to chose different implementation (by using for example factory pattern)? i can see it working for com.bea.xml (XSD types) and com.bea.xbean.values (implementation) - this is very valuable set of Java classes providing XSD validation (even more if they were more abstract so could be used with any XML databinding). thanks, alek -- If everything seems under control, you're just not going fast enough. Mario Andretti - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote for XMLBeans proposal
Berin Lautenbach wrote: Ted Leung wrote: Nicola Ken Barozzi wrote: If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) I'm happy to invest some time in helping XMLBean get throught the incubator -- speaking with my XML PMC and ASF member hat on. The idea of moving XMLBeans to incubation under the XML project and with the assistance of Ted gets a +1 from me with some caveats : 1. Current XMLBeans committers need to be comfortable with this resting with the XML project in the first instance. Note that I would hope that the umbrella project could be changed prior to exit from incubation if the feeling from the committers was that it should be. If the initial preference is Jakarta then please indicate! I'm definitely not trying to push a line here, and it's easy to switch the vote over to the Jakarta PMC :. 2. Committer issues that have previously been discussed will need to be worked through during incubation (although that's really what incubation is about :). +/- from other XML PMC members welcome. Further discussion also welcome! hi, based on what I have seen when looking on XMLBeans source code and (limited) design documentation I beleive that this project is very interesting and useful for Web Services so I have CCed [EMAIL PROTECTED] mailing list too. It seems that BEA folks are willing to solve all remaining problems and I think that it would be good if this project quickly gained more mementum and I am willing to help with it (even though I am not Apache XML commiter) thanks, alek -- If everything seems under control, you're just not going fast enough. Mario Andretti - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
