Currently we try to infer the JAXBContext only from the class object of the actual test result. However there are situations in which the context might not be complete because not all available XML types can be statically reached from this class. Now, if you have a modular XSD model it might happen that the actual object has references to to another object which XML type is not part of the JAXBContext.
When serializing such objects to an XML string, the result might lack required namespace definitions.
To fix this, you can manually pass in a JAXBContext via XmlSnapshot.xml().withJAXBContext(...). However, if you have a big model, it might be cumbersome to list all the top-level classes or package names in JAXBContext.newInstance(...)
For this purpose we could provide a little class path scanning util (or ship with a dependency to https://github.com/classgraph/classgraph) in order to automatically list all elligible packages under a passed in base name.
As a draft:
XmlSnapshot.xml()
.withJAXBContext(JAXBContextBuilder
.withClassLoader(getClass().getClassLoader()) // Optional
.addPackageOf(com.foo.x.ObjectFactory.class) // Adds the single package com.foo.x to the context
.addPackage("com.foo.y") // Adds the single package com.foo.y to the context
.addPackagesBelow("com.foo") // Finds all elligible sub packages of com.foo and adds them to the context (all packages containing a class named ObjectFactory)
.addPackagesBelowPackageOf(com.foo.SomeClass.class) // Finds all elligible sub packages of com.foo and adds them to the context (all packages containing a class named ObjectFactory)
.build() // Create the JAXBContext
)
...
The JAXBContextBuilder could come with an internal cache so that clients don't need to care about reusing the context.
Question remains whether these convenience stuff should be part of this library or not
Currently we try to infer the JAXBContext only from the class object of the actual test result. However there are situations in which the context might not be complete because not all available XML types can be statically reached from this class. Now, if you have a modular XSD model it might happen that the actual object has references to to another object which XML type is not part of the JAXBContext. When serializing such objects to an XML string, the result might lack required namespace definitions.
To fix this, you can manually pass in a JAXBContext via
XmlSnapshot.xml().withJAXBContext(...)
. However, if you have a big model, it might be cumbersome to list all the top-level classes or package names inJAXBContext.newInstance(...)
For this purpose we could provide a little class path scanning util (or ship with a dependency to https://github.com/classgraph/classgraph) in order to automatically list all elligible packages under a passed in base name.
As a draft:
The
JAXBContextBuilder
could come with an internal cache so that clients don't need to care about reusing the context.Question remains whether these convenience stuff should be part of this library or not