BEA Releases XMLBeans to open source

Discussions

News: BEA Releases XMLBeans to open source

  1. BEA Releases XMLBeans to open source (32 messages)

    BEA has released XMLBeans to the open source community under the Apache-style license. XMLBeans take XML documents, and give developers a Java-based view on the data. These Java classes enable easy read/write access to XML information and enforce XML Schema constraints.

    The GA version of XMLBeans is now available for download on http://workshop.bea.com. You can now download the full XMLBeans kit and compile schemas offline as well as use the hosted service.

    Source code and binaries for XMLBeans are now publicly available via an Apache-style license from this site. XMLBeans are FREE for everyone to use as they wish. To my knowledge, this is the first time BEA has released something to "open source".

    BEA has proposed to the Apache group that they start a sub-project there for XMLBeans. There is a long road ahead before they could actually form an Apache project, but they are hopeful that they will be successful in finding XMLBeans a home there.

    Read all about XMLBeans

    Threaded Messages (32)

  2. XMLBeans or JAXB[ Go to top ]

    What is the difference between XMLBeans and sun's JAXB. I think both are for the same thing - transition from XML to Java based on XML schema. So what to choose for XML projects.
  3. XMLBeans or JAXB[ Go to top ]

    I *believe* that the fundamental difference is that you can read in an XML document - and write it out again - and the written XML document will be 100% identical to the original - including, formatting, whitespace etc etc.

    This is useful when you care about the formatting of the document - e.g. for versioning, and legal documents etc.

    -Nick
  4. XMLBeans or JAXB[ Go to top ]

    XMLBeans is a competing technology to JAXB and SUNW's RI. The goal is exactly the same. I don't know whether one is faster than the other. IMHO XMLBeans should implement the JAXB interfaces.
  5. XMLBeans or JAXB[ Go to top ]

    The FAQ has some information how how it is being positioned with regards the JAXB spec and Castor.

    http://dev2dev.bea.com/technologies/xmlbeans/faq.jsp
  6. XMLBeans or JAXB[ Go to top ]

    JAXB and XmlBeans are different in several significant ways and BEA is supporting both. BEA is represented on the technical committee for the JAXB JSR and is intent on moving JAXB forward and helping it be successful. If developers are looking for a Java-XML technology that is JCP compliant then JAXB 1.0 has a reference implementation and is an important option to consider.

    When doing development for the Weblogic Platform 8.1 release it became increasingly apparent to us that there we needed a java solution that would optimize XML Schema compliance. That is a major difference between the goals of JAXB and XmlBeans. XmlBeans' explicit goal it reach 100% schema compliance. Another goal was to keep the underlying XML Infoset intact So, if you need to drop down into a lower level DOM like API (called XmlCursor in XmlBeans) you can at any point. Also, there is a rich "reflection-like" API that allows you to access the schema information if needed.

    JAXB is an important, valuable specification that will continue to grow and improve. BEA will be working closely on JSR 222 (JAXB 2.0) to help JAXB 2.0 and XmlBeans type functionality come together. Also, I think implementing the JAXB 1.0 interface is doable and is likely.

    There has been several posts on the Apache proposal that relates to this type of question.

    http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansExplanation
    http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansRoadMap
    http://archives.apache.org/eyebrowse/ReadMsg?listName=general at xml dot apache dot org&msgNo=587&raw=true

    thx,
    Dave Remy
    Program Manager, XmlBeans
  7. Standalone XQuery support[ Go to top ]

    Just wondering if there is a timetable you could share with us :-)
  8. I WANT MY XQUERY![ Go to top ]

    Just wondering if there is a timetable you could share with us :-)


    I'm just hooked on XQuery (the Kawa implementation).

    But I can't do the following:

    - XQuery can't handle typical HTML crap, so it can't replace JSP, which ignores HTML (accounting for its success). Such a shame for XQuery where tags are first-class citizens

    - Kawa can compile xquery down to bean, so you can get from xquery to java, but what the f- method do you call, and how do you parameterize it?

    - what the f- do you reference within the XQL for parameters passed in?

    - how do you write to a g-damn file from XQL in a standard way?

    - Java can't call XQuery yet

    - can't have subordinate XQLs to template JSPs -- doesn't work, some g-damn null pointer exception

    - we're never going to get rid of all this HTML crapola. Neither XQuery or XSLT is able to handle all the crap that exists in HTML, because they care about tags and whether stuff parses or not.

    Best Regards
  9. XMLBeans or JAXB[ Go to top ]

    I think that this release is great. I was following the JAXB specifications from day one. The first release was very deceiving since only DTDs were supported. At that time Castor was a great package (and still is !).
    Then the JCP community realised that nobody was really using JAXB and then rewrote the spec to support schemas. Personnaly I find JAXB to be too complicated for what it is trying to achieve. No extra files (mapping, ..) should be written to support the transformation. XML Schema is rich enough to support any constraints.
    Now people are wondering why they should be using JAXB, Castor, XMLBeans. I would say, just use the tool which fits your requirement the best. For me it is a combination of: ease of development + ease of deployment + fast. After reviewing multiple XML marshaling/unmarshaling projects, it is clear that JAXB is not (yet) suitable for me.
  10. XMLBeans or JAXB[ Go to top ]

    We have also looked at JAXB for use in the NetBeans/SunONE Studio IDE and concluded that JAXB does not meet the requirements that development tools have. So we have our own (open source) framework for XML file manipulation, which does meet them:

    http://schema2beans.netbeans.org/

    To me it seems that schema2beans is in many ways comparable to XMLBeans. Its goal is also to 100% preserve the original document, including white space. Additionally, we need some support for incremental changes in the document, i.e. that if an element is added to the XML document, the framework fires an event to its listeners saying "this and that element has been added". This was explicitly stated as a non-goal for JAXB from the very beginning, and I think it is fine to create one's own framework which satisfies these additional requirements.

    BTW, there is a JSR submitted by BEA called Streaming API for XML (StAX, JSR 173), which I believe was motivated by BEA's work on XMLBeans. After looking at it briefly, it looks to me as a very useful XML parsing technology, which will make the development of frameworks such as XMLBeans much easier.

    Petr Jiricka
    Sun Microsystems/NetBeans
  11. XMLBeans or JAXB[ Go to top ]

    Hi

    I have had bad experiences with JAXB when deployed in a J2EE app; as it currently stands I would *not* use JAXB.

    If you use it test in container to avoid class loading/path issues.

    Jon.
  12. Has anyone been able to get the scomp.cmd to work on their system as spec'd in the README? I've followed their recommendations for both command line and ant target builds, and I get this:

    $ scomp.cmd -nopvr easypo/
    Loading schema file easypo\easypo.xsd
    Loading config file easypo\easypo.xsdconfig
    Time to build schema type system: 2.043 seconds
    java.io.IOException: CreateProcess: "C:\Program Files\Java\j2re1.4.1_02\..\bin\j
    avac.exe" -J-Xmx256M @c:\DOCUME~1\prexer\LOCALS~1\Temp\javac11325 error=3
    null
    java.io.IOException: CreateProcess: "C:\Program Files\Java\j2re1.4.1_02\..\bin\j
    avac.exe" -J-Xmx256M @c:\DOCUME~1\prexer\LOCALS~1\Temp\javac11325 error=3
            at java.lang.Win32Process.create(Native Method)
            at java.lang.Win32Process.<init>(Unknown Source)
            at java.lang.Runtime.execInternal(Native Method)
            at java.lang.Runtime.exec(Unknown Source)
            at java.lang.Runtime.exec(Unknown Source)
            at java.lang.Runtime.exec(Unknown Source)
            at com.bea.xbean.tool.CodeGenUtil.externalCompile(CodeGenUtil.java:167)
            at com.bea.xbean.tool.SchemaCodeGenerator.compileTypeSystem(SchemaCodeGe
    nerator.java:178)
            at com.bea.xbean.tool.SchemaCompiler.compileImpl(SchemaCompiler.java:547
    )
            at com.bea.xbean.tool.SchemaCompiler.main(SchemaCompiler.java:141)
    BUILD FAILED
  13. XMLBeans Setup help[ Go to top ]

    Pete,

    It looks like that's because you're running out of the JRE rather than the JDK (i.e., you have j2re1.4.1_02 rather than jdk1.4.1_03). The JRE doesn't include java compilers, jar.exe, or other tools you need for development. The XMLBeans schema compiler depends on the JDK's java compiler to compile the java code.

    (The win32 error number 3 you're getting is "path not found" and is indicating "C:\Program Files\Java\j2re1.4.1_02\..\bin\javac.exe" doesn't exist on your machine.)

    Once you have the JDK installed, make sure that JAVA_HOME is set to point to it rather than the plain JRE.

    Cheers,

    David
  14. Congratulations BEA[ Go to top ]

    This is great Another good company

    doing things to the open source

    i take a look
    and the documentation is not good

    is very confused

    But congratulations BEA, good way to do good things
  15. XMLBeans[ Go to top ]

    The documentation for XMLBeans is fantastic in the Weblogic Workshop 8.1 downloads. I suspect that when the final product ships this summer, it will be much more exhaustive.

    As for XMLBeans, they are very different from JAXB. They treat XML documents as first class citizens, meaning that the document doesn't go through a conversion into Java where integrity of the document can be lost. XMLBeans creates a cursor that can move through the XML document. You can access any element of the document, including comments and schema information because the document is kept in full fidelity. It also creates the opportunity to execute an XQuery on the document, to do specialized maneuvering, etc. XMLBeans also gives a strongly typed access to the document and a more generic type of access, similar to a reflection API.

    I've found it to be powerful and easy to use in the couple of prototypes I have done. Within Workshop, you just drop an XSD into your project and the XMLBeans are created and availalble throughout the entire EAR. It certainly saves you time.

    Anyways, it is a technology worth checking out. This is the first I've heard of XMLBeans being pushed into Apache. If that is the case, I think our product managers are making some smart moves.

    Tyler Jewell
    Director, BEA
  16. XMLBeans[ Go to top ]

    Obvious Tyler knows much more about the implementation details of XMLBeans and based on his description they are different from SUNW's JAXB-RI. However, at a high level both are trying to solve the same problem, and I still think it is beneficial for XMLBeans to support the JAXB API.
  17. XMLBeans[ Go to top ]

    Obvious Tyler knows much more about the implementation details of XMLBeans and

    > based on his description they are different from SUNW's JAXB-RI. However, at a
    > high level both are trying to solve the same problem, and I still think it is
    > beneficial for XMLBeans to support the JAXB API.

    Since XMLBeans will become open source it's possible for anyone who's interested in seeing this happen to contribute.

    Of course, this assumes that both architectures are compatible. If the architectures have unreconcilable differences then forcing XMLBeans into the JAXB-RI mold would still be possible (with the right facade), but it would likely be a bad idea -- the abstraction missmatch would leak out one way or another.
  18. XMLBeans / JAX B[ Go to top ]

    XMLBeans set out with some different design goals and principles from other binding solutions (which I think are best explained on http://workshop.bea.com/xmlbeans/quickStart.jsp).

    We've tried to be as consistent with the JAX:B API as possible, but in areas where we had additional functionality or needed to adjust APIs based on our greater focus on schema coverage we had to extend beyond JAX:B a bit. Its our intention that XMLBeans will support the JAX:B APIs over time.
  19. XMLBeans / JAXB[ Go to top ]

    Perhaps I should clarify too -- its our intention that XMLBeans _fully_ support the JAXB APIs over time. We support a good portion of them now.

    There are no major architectural problems that would inhibit us from doing this that we can forsee.
  20. XMLBeans[ Go to top ]

    I just want to quickly clarify my own post on XMLBeans vs. JAX:B. I was referring to the underlying architecture for implementation, not necessarily compatibility or API adherence. As David points out, the FAQ on dev2dev is quite exhaustive in explaining how XMLBeans works and how the technologies are complementary.

    Tyler
  21. I find it very strange that JAXB and XMLBeans do not support a very common and simple business need - marshalling existing objects to XML. Sometimes I can't use a schema compiler to generate classes for marshalling, sometimes they are just given. Also, sometimes they are not of concrete class types, all I have is an interface. If I have an object and a schema and a object->schema mapping plan, what can be the problem? Example? There's a big fat one - entity beans, and I simply can't see how can Sun leave this gaping hole in JAXB spec nor how can BEA, IBM et al leave customers without a solution.

    Castor otoh comes pretty close to it, but he can't work with interfaces.
  22. Existing classes to XML[ Go to top ]

    Could you clarify whether you have a schema for your serialized objects? In the first part of your question you say that you can't use a schema compiler, but later you mention that you do have a schema.

    For EJBs, I believe that the intent is that EJB state can be passed as XML beans in parameters, rather than a single class implementing both XmlObject and EntityBean. However, such restrictions would not generally apply to other classes.
  23. Existing classes to XML[ Go to top ]

    <quote>
    Could you clarify whether you have a schema for your serialized objects? In the first part of your question you say that you can't use a schema compiler, but later you mention that you do have a schema.
    </quote>

    The fact that I can make a schema for the classes doesn't mean I can use a schema compiler. Problem is that I have no use for generated classes because I already have the classes I want to marshall. :)

    <quote>
    For EJBs, I believe that the intent is that EJB state can be passed as XML beans in parameters, rather than a single class implementing both XmlObject and EntityBean.
    </quote>

    Pass EJB state as XML beans in parameters? Can you please elaborate a bit on this?
  24. Existing classes[ Go to top ]

    OK, so the problem is that you want to merge or mix-in the XMLbean classes to your existing application classes rather than have to map between them. In many cases you should be able to go ahead and inherit the XMLObject class, but naturally this won't be straightforward for classes like EJBs which have their own concept of creation etc.

    Otherwise mapping is the order of the day - no way out of that that I can see. What steps would you see being automated in this situation?

    For EJB state, whether a single field or the whole thing, EJB method parameters can be declared as an XMLObject subtype. This is serializable so you can get complex structures transferred relatively easily to a Web Service layer or similar.
  25. I find it very strange that JAXB and XMLBeans do not support a very common and simple business need - marshalling existing objects to XML.

    JSX or Koala work well. They're open source Java and make it very easy to marshall arbitrary object graphs.
  26. Betwixt[ Go to top ]

    Betwixt, a Jakarta commons project, does the same thing. It works superbly with beans. I believe it as at 1.0 Alpha at the moment, but I have successfully used in production to easily move data into our XSLT display tools.
  27. <quote>
    JSX or Koala work well. They're open source Java and make it very easy to marshall arbitrary object graphs.
    </quote>

    It was quite some time ago when I evaluated different libraries, but as far as I remember most of them had some kind of a problem with entity beans. I have to admit I never tried betwixt though, I'll try it right away. :)

    Anyway, my troll was not directed at OS, it was directed at companies that make enterprise specs and solutions but fail to integrate them for some reason. On the other hand "integration", "synergy" and simmilar buzzwords are all over their web sites and marketing materials. :)
  28. XMLBeans are really elegant. I just downloaded the pkg and wrote some examples. You basically don't worry about un/marshalling or mapping the xml elements to your class memebers. You run scomp.sh on you .xsd file and rightaway you can use the java objects generated for you. Just put the generated jar in your cp and your done.
    Thanks BEA for making that available to the open source.
  29. Multiple schema support?[ Go to top ]

    The package looks cool from what I've seen so far....

    I have some SOAP code that I wrote using JDOM and I'm wondering if XMLBeans might be better. I have a schema for my SOAP messages, and JDOM/Xerces is validation my SOAP messages using the SOAP schema and my own schema. Would XMLBeans be able to compile the SOAP and customer schemas together so I can do this using Java types instead of generic JDOM Elements?
  30. Multiple schema support?[ Go to top ]

    Greg writes: "Would XMLBeans be able to compile the SOAP and customer schemas together so I can do this using Java types instead of generic JDOM Elements?

    Yes, absolutely. You can either (1) pass as many schemas to the schema compiler at once as you want, or (2) if you want to use two schemas together that don't have direct dependencies on each other (e.g., via wildcards), you can compile them separately and put both jars on your classpath at the same time if you want.

    Your first step is to go ahead and try compiling the schemas and writing a little simple code get a feel for how XMLBeans works. You should find that it's pretty straightforward to do simple web services work with XMLBeans.

    As you make progress, if you have questions, there is a support community at bea.com that is monitored by the developers:

    http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=xover&group=weblogic.developer.interest.xmlbeans&utag=
  31. XMLBeans is a great product that makes accessing XML seamless and beats all other existing XML binding frameworks. The fact that BEA has made it free lowers the entry barier for new XML adopters to zero. My congradualtions to Chris and other BEA engineers! Great job!
  32. http://xml.apache.org/xmlbeans/[ Go to top ]

    http://xml.apache.org/xmlbeans/
  33. I had the same problem try adding
    -compiler c:\jdk\bin\javac.exe
    obviously replace this path with the fully qualified path to your javac.exe