Unmarshalling an XML fragment representing a JAXB object without XmlRootElement I've recently had a requirement to unmarshal an XML fragment that was passed into one of my services. This in itself is typically not and issue and I've written code that does that plenty a time, however in this case I was having to unmarshal a fragment for a complex type, not for an element. That's where it got a little bit more complicated.
Generate JAXB jar from a Maven dependency that has multiple referenced schemas I've been trying to get the maven-jaxb2-plugin to generate a JAXB jar out of XSDs that are stored inside a dependency that I have no control of. This was quite doable for a simple, single XSD Maven dependency that didn't import any other schemas, but when dealing with a more complex schema that did import multiple other XSDs from the same dependency jar, it didn't "just" work. After trying many approaches I found a solution however.
How to determine the JAXB runtime version I've had to confirm which JAXB version I've been using for my runtime. In my search through various forums I've come across some code that more or less worked, but it wasn't very robust and wasn't explained well. I've put this together to answer the question properly.
JiBX fails to generate Java XML bindings for schemas with circular references I wanted to compare how JiBX stacks against JAXB in terms of performance. From their website, they claim "It also provides very high performance, outperforming all other Java data binding tools across a wide variety of tests.". This sounded great, especially since I've identified that JAXB is a bottleneck. I downloaded JiBX 1.2.6 and proceeded to generate my bindings, only to find that it could not handle my schema.
Performance difference between JAXB and Velocity generating XML fragments One of the peculiarities we've noticed during our recent bout of performance testing at work was how much JVM heap space was being used and immediately garbage collected by one of our web services. The figures were quite staggering, with a peak use of 3Gb to generate the response message in some cases. This was not impacting the performance of the system overall, but still needed investigating as it gives lots of room for improvements.