READ THIS BEFORE WORKING ON THIS CLASS!
There are a couple of hidden issues that this class deals this:
-
JAXBContext instances are cached by the REST framework (and then reused
with *all* request). This means that we can not provide multiple JAXBContext
instances, but must make sure that an instance of this class is cached -- which
will then provide different (un)marshallers depending on the deploymentId used
in the request.
This means that when the extended methods are called (JAXBContext.createMarshaller()
for example), we then look at the internal cache to retrieve the correct
JAXBContext).
- As we've recently discovered, because certain CDI frameworks (openwebbeans, among others)
do not delegate the
Object.equals(Object) method, this class can and must not
be a CDI bean.
- Different deployments may have different versions of the same class. This means that
We can not use 1 (internally cached)
JAXBContext instance to deal with
all deployments. Tests have been specifically created to test this issue.
- Concurrency: this is an application scoped class that is being acted on by multiple
REST request threads. Fortunately, we just handle normal REST requests (no comet, for
example), so the requests themselves (with regards to the serializaiton logic) are all
handled in one thread.
With regards to classloading and related issues, these rules apply:
-
Implementations are open-ended; anyone can implement those interfaces, even by different people from different modules, provided they are all given to the JAXBContext.newInstance method. There's no need to list all the implementation classes in anywhere.
Each implementation of the interface needs to have an unique element name.
Every reference to interface needs to have the XmlElementRef annotation. The type=Object.class portion tells JAXB that the greatest common base type of all implementations would be java.lang.Object.
In all cases, please preserve existing tests when modifying this class!