I am starting a new project where I have third party XSD. My Java application needs to generate, and readm XML messages that conform to this XSD. In the past I have used Apache XMLBeans for this. It looks like XMLBeans has been retired.
What is a good replacement for XMLBeans now that it has been retired? I have used XStream on other projects but I don't recall that XStream has the ability to generate Java classes from an XSD so I am thinking that it is not a good choice over XMLBeans for this use case. I have hundreds of types defined in the XSD and would really prefer not to have to create the hundreds of Java classes to represent them in Java by hand.
In other words, using the XStream example, I have a Person type (and 99 others) defined in the XSD. Using XMLBeans I can generate the Java classes to represent these objects, but using XStream I would need to create the Java classes (e.g. Person) by hand or using some other tool. What tool should I use in this case?
Have you looked at JAXB? I haven't done anything with either of these, but googling for "alternative to XMLBeans" brings up lots of references to this package. Here's an article that compares them...
http://blog.bdoughan.com/2012/01/how-does-jaxb-compare-to-xmlbeans.html
XMLBeans has been unretired:
The Apache POI project has unretired the XMLBeans codebase and is maintaining it as a sub-project. Until now the XMLBeans codebase was held in the Apache Attic where former Apache projects are kept for the public good.
The latest release as of August 2020 is:
3.1.0 (March 26, 2019)
Having said that, I am not sure I would recommend using it, based on its history of retirement. Other solutions, such as JAXB, might be prefered since it will probably be better maintained in the future.
Related
We wanted to upgrade our project in order to use some up-to-date dependencies. In the moment we use jaxb for XML reading and writing. This is working very good.
In some cases we do not have an xsd or dtd in order to generate the java classes (via xjc). In those cases we use dom4j for creating xml documents or dom4j with xpath for reading xml documents.
The version 1.6.1 is over ten years old and as far as I understand, dom4j needs jaxen as the X-Path library. Jaxen 1.1.6 is also 4 years old. Also we removed from our project xerces 2.40 (also 12 years old).
What XML API is state of the art in the moment? It should support XPATH expressions and should create and read xml documents.
Also I am wondering about xerces. When we use JAXB for reading xml documents, sometimes we have an object values instead of a string, date or something else.
The reason for that is that somebody messed up the xsd and forgot do define a datatype for some elements. XJC creates simple object properties inside the generated java class. The strange thing is, that I needed to cast the object to an "ElementNSImpl" object. This object comes from the xerces project.
I am a little bit confused. Our solution for removing xerces was to define each element with a proper datatype. Unfortunately those XSDs are third party XSD and we have to fix that each time the XSD will change. But why do I have to cast the object in ElementNSImpl?
Thanks for your help.
Just because something is 'old' doesn't mean it's not useful. DOM4J is still my favorite tool for ad-hoc XML processing. dom4j has been updated since 1.6.1, but note that it is still dependent on an underying XML parser (such as Xerces).
dom4j version 1.6.1 has an XML Injection security vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2018-1000632.
It appears to have been fixed in 2.1.1, released in July of 2018.
I have an application that receives an XML message and then parses it to perform further processing.In order to have this working in my application, after receiving the XML string, I call the JAXB marshaller to marshal it in to java POJOs and the processing takes from here after.
This thing works well till the time I have one version of XML.
Problem
But the problem comes when there are more than one versions of the same XSD. And my application has to deal with both version of messages. Clients to my application may send a old version xml or they may send a latest version XML.
For JAXB I have to convert the XSD into java pojos using JAVA XJC tool, and the problem arises when I convert the latest version of XSD it has the same class names as the previous version, but internal fields and hierarchy of the class is different. this causes problems even if i put the XJC outputs in different jars for each version.
Expected Solution
This change in version is expected to happen every 6 months and I have to make my system able to read the newer version XMLs also alongwith the old versions.
I want to know how to manage this XML processing in JAVA with JAXB or some other framework.
Shall I use SAX Parser? I have read that its not that efficient as compared to JAXB. And after working on SAX parser for last few days, i found out that it can be error prone as it involves looking for each element and getting values out of it and putting it into a java structure of our own and that is a lot of effort as compared to JAXB.
*
Question
Is there any simple solution similar like JAXB ?
*
Temporary Solution Used
I have used a temporary solution, with which i am not happy as a good solution. What I did is, I created a seperate jar for each XSD version using XJC tool. And created different packages ion each jar e.g.
1. Pojos for version 1.2 are in a jar with base package com.cgs.v_12
2. Pojos for version 2.0 are in a different jar with base package com.cgs.v_20
i have added both as a maven dependancy to my system and using them for processing different versions.
For JAXB/ any other solution that maps between XSD -> POJOs, this will be a 1-1 mapping, especially if the POJOs are generated.
Do you have to
(1) map the entire XML to POJO, or
(2) a subset of that XML to a static/ fixed POJO model?
If (1), since the changes in the subsequent versions cannot be anticipated, I believe the solution for the above will be use a strategy pattern to select the correct JAXB artifacts based on the version
If (2), you can explore using XPATH, defining XPATH mappings per version.
Is anyone aware of a library that makes the process of creating XSDs in Java a little easier than using something like a DocumentBuilder? Something like a helper or utility class. I came across the org.eclipse.xsd maven jar but I'm having ClassNotFoundException issues when working with it in Eclipse and I'm not entirely sure it's meant to be used as a standalone kind of thing. This is a bit difficult to Google for as well since there are lot of search results around automatic generation/translation from Java to XSD and vice versa.
Essentially what I need to do is to programmatically create an XSD from a certain source of data -- not Java classes.
Apache XMLSchema is a lightweight Java object model that can be used to manipulate and generate XML schema representations. You can use it to read XML Schema (xsd) files into memory and analyze or modify them, or to create entirely new schemas from scratch.
The fact that with this API one can create an XSD from scratch, it sounds as a starting point to achieve the ask; as to the fitness, it depends on what that "certain source of data" is.
My issue is summed up nicely here, http://tech.groups.yahoo.com/group/jena-dev/message/33894 which also proposes a solution. Problem is stated solution requires access to the code, and I'm only working with a binary distribution of the software. Anyone know what else I can do, if there's a jar file I can download from somewhere/add to classpath? There's various versions of XercesImpl.jar that I've tried, all resulting in various other errors. Any help greatly appreciated!
Apache Jena currently depends (at compile and runtime) on Apache Xerces (i.e. xerces:xercesImpl:2.10.0) therefore Apache Xerces cannot be removed without source code changes.
Xerces is used for RDF/XML parsing and for Datatypes.
In an ideal world, the RDF/XML parsing could be in a separate module (i.e. jena-rdfxml) which would continue to depend on Apache Xerces and the Datatypes would need to be reimplemented without relying on Apache Xerces. This way, you could use a jena-core module with no support for RDF/XML and not dependency on Apache Xerces.
May I ask you why you need or want to remove xercesImpl.jar from your classpath?
See also:
https://issues.apache.org/jira/browse/JENA-189
https://issues.apache.org/jira/browse/JENA-191
Since 3.8.0, Jena no longer depends on Xerces: https://issues.apache.org/jira/browse/JENA-1537
Because of increasing configuration complexity, I want to introduce XML for my library's configuration files, and replace the existing properties files.
I would like to
Publicly describe the XML structure with XSD (so the structure is documented and can be versioned)
If possible, generate Java source code from that XSD for unmarshalling (like with JAXB / XJC). An alternative simple access method is OK too (e.g. simple XPath expressions)
Have a low footprint and few or even none additional dependencies
If the footprint wasn't an issue, I'd choose JAXB right away. Are there similar libraries with a lower footprint?
EDIT: By footprint, I don't mean consumed memory but the "size" of the library in KB/number of classes. I'd expect my rather simple use-case to be coverable by a library with about 5-6 classes. I don't need the full power of JAXB.
JAXB is Low Footprint
A JAXB (JSR-222) implementation is also included as part of Java SE 6. The classes produced are just POJOs with the necessary annotations. In the question below the poster observes that the XMLBeans classes are four times bigger than the JAXB classes.
Compiling huge schema into Java
Reducing the Number of Classes
If you start with Java classes (instead of generating them from an XML schema) you can normally keep the model smaller. The use of #XmlWrapperElement can help eliminate classes.
Reducing the Number of Classes Further
You can leverage the #XmlPath annotation in EclipseLink JAXB (MOXy), note I'm the tech lead. It leverages XPath to extend the JAXB mappings:
http://bdoughan.blogspot.com/2010/09/xpath-based-mapping-geocode-example.html
For a zero-dependency solution use the DOM or the SAX parser that is part of every Java VM.
If you want Java type binding, stick with JAXB. Even if you find a smaller size library, you will loose out by using a non-standard solution that hasn't been as extensively tested or has as many developers who know how to use it.
If you are willing to consider using non XML-technologies, then you might want to look at my Config4J library (www.config4star.org). Comparing it to your wish list...
It provides an easy-to-use schema language.
The jar file is small (102KB) and it has no external dependencies.
The one capability missing from your wish list is a tool to automatically generate Java classes from a schema definition. However, the API of Config4J is simple enough that I'm not sure you would need such a code generator. Part III (The Config4JMS Case Study) of the Practical Usage Guide manual describes a technique for building a Spring-like library to create Java objects from configuration information.