We are using Castor for marshalling/unmarhalling xsd:s. We are using attachments and refering to the with the "swaRef" element. According to this page Castor does not support this, http://docs.codehaus.org/display/CASTOR/Castor+JAXB:
Some of the functionality could require to be actually implemented in
backing Castor framework - for example handling the attachment
through MTOM/XOP and swaRef.
How can we overcome this limitation?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
My recommendation would be to use a standard JAXB (JSR-222) implementation that supports everything you need (models generated from XML schema, swaref, etc) rather than implementing some workaround to use Castor. An implementation is included in the JDK/JRE as of Java SE 6, and other implementations (such as MOXy) are also available.
Note
Based on the link you provided it does not appear as though Castor has run the JAXB (JSR-222) compliance tests and in the "Functional testing" section on that page it appears as though Castor has not fully tested its support for the JAXB (JSR-222) annotations.
Functional testing
I think a little bit of time should be spend on
functional testing, and this might get quite tedious. Looking, for
example, at the #XmlAttribute annotation, there's a lot of variants to
test, requiring POJOs to be annotated slightly different for each test
case. That would require us to write a lot of POJOs and wire them up
accordingly in the test classes. Let's see whether we can agree on how
to go about this (layout, package structures, ...).
Related
I don't understand why PowerMock use javassist library and Mockito is not.
Most of the conversations about code generation libraries in Java circle around three libraries: cglib, javassist, and ByteBuddy. Mockito was formerly on cglib, but now uses ByteBuddy as its default code generator.
As ByteBuddy author Rafael Winterhalter notes here:
javassist offers an API for modifying classes and not only for subclassing them. These APIs allow also for byte code-level manipulation while cglib only allows for several hardcoded interceptions.
Though I am not a contributor on any of these mocking frameworks or libraries, it's worth noting that Powermock works in part by editing class implementations to intercept calls to private, static, and final methods and classes within compiled bytecode. This likely explains the requirement to use javassist from Powermock: cglib was not capable of editing existing classes. Mockito, in contrast, needs simpler code generation in order to generate a subclass of the given class; this is functionality that cglib and ByteBuddy were written to provide.
Note that open Powermock issue 727 tracks an incomplete migration of Powermock from Javassist to ByteBuddy.
Now, the reverse: Why doesn't Mockito switch to Javassist instead of ByteBuddy? Again, we don't have a direct answer, but the ByteBuddy tutorial expresses an opinion (under "General Information" for Javassist, emphasis mine):
This library comes with a compiler that takes strings containing Java source code which are translated into Java byte code during the runtime of an application. This is very ambitious and in principle a great idea since Java source code is obviously a great way for describing Java classes. However, the Javassist compiler does not compare to the javac compiler in its functionality and allows for easy mistakes when dynamically composing strings to implement more complex logic. Additionally, Javassist comes with a proxy library which is similar to the JCL's proxy utilities but allows extending classes and is not limited to interfaces. The scope of Javassist's proxy tools remain however equally limited in its API and functionality.
In short: There is anecdotal reason to doubt Javassist's safety/functionality/stability. Mockito did not require Javassist's features, so it could migrate straight from cglib to ByteBuddy. PowerMock did require Javassist's features, and the efforts to migrate PowerMock to ByteBuddy are stalled and ongoing.
Is it possible to create Prolog-specific bindings of XML schema files? If so, can anybody point me in the right direction?
I have a schema which I use in Java to create a JAXB binding to serialize and de-serialize XML files. These files are created by an SWI-Prolog application which is still evolving and is developed by a geographically distant team. I want to make sure that when XML format changes, they are tied to a schema file change and not just view a schema as a nice documentation tool which often lags their actual XML content.
Any suggestions are appreciated.
Sounds like the general consensus is to use Prolog's JPL package to wrap a JAXB binding in Java. This is the closest one seems to get to an actual binding implementation.
There is an SGML package which is used by many, but this is not a binding. As far as I understand, the best one can hope for is to be able to validate one's XML against the schema, but a quick look at the SGML documentation did not give me an impression that this functionality is actually fully implemented.
So, if one needs a schema binding-style XML management framework, the recommendation is to access JAXB binding of this schema via JPL. Some folks expressed stability concerns of JPL. They reported frequent crashes of JVM when using JPL, but I have not independently verified these claims and thus cannot confirm them. If anybody has more input on this topic, I would love to get it.
Thanks
The optaplanner uses XStream for reading the solver configuration from XML. For using JAXB instead, is it sufficient to have custom implementation of XMLSolverFactory and SolverConfig?
No, because the *Config classes aren't annotated with JAXB annotations in 6.0.0.
There's a open discussion if we want to migrate from XStream to JAXB, so we can offer an XSD of the solver config.
Also note, that these 2 things are completely distinct:
read a solver configuration from XML
read a solution dataset from XML (~ProblemIO)
For 2), you can very easily replace XStreamProblemIO with a JaxbProblemIO (which should be easy to write).
I've been using the default Sun JAXB implementation that ships with the Oracle JDK 1.7.
Unfortunately I have certain quite complex XSD schemas to work with and I've hit what appears to be a bug in the XSD to Java engine (described in this SO post).
It appears that only a workaround is possible and what's worse I haven't yet been able to apply the particular workaround in my individual case. What's more unsettling however is that a workaround should be required for what is in my view a very elementary case (one XSD schema referencing an element defined in another).
I know of at least two other JAXB implementations:
Apache Camel
EclipseLink MOXy
Would anyone have any insights into how these compare against each other and against Sun's JAXB ?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
Apache Camel - I believe Apache Camel just leverages JAXB and is not a JAXB
(JSR-222) implementation itself.
EclipseLink MOXy - There are many great reasons to switch to MOXy (XPath based mapping, external mapping metadata, JSON-binding, etc). But MOXy uses the XML Schema to Java Compiler (XJC) tool from the JAXB reference implementation so it won't fix this use case.
when i compile a JAXB schema the generated classes are decorated with generic Javadoc comments.
is it somehow possible to suppress generating these comments?
Annotation to disable JavaDocs
Not if you're using Sun's JavaDocs tool.
They have a feature request for it, but it's been in low priority since 1997.
You can write a custom doclet to overcome this, or use a 3rd-party tool (DocFlex or such).