Open beikov opened 5 years ago
After looking into how JSON binding could be supported, I think it's a better idea to have a thread local context that holds the current EntityViewManager
and use an empty constructor that accesses that EntityViewManager
instead of accepting it as parameter. This way, I think we can make it work the same way for all serialization/deserialization frameworks.
I'm deferring this as it requires #913 which will take a while and isn't scheduled yet. Also, I think XML usage is rather rare nowerdays, so it's not that important to have it initially. I still want to do it though, but not now.
This depends on https://github.com/Blazebit/blaze-persistence/issues/1044 as our integration will need to do the following
@XmlAccessType
@XmlElement(type = ViewImpl.class)
@XmlElement
/@XmlAttribute
to getters in implementation except for the id@XmlElement
The JAXB unmarshaller will need to provide the implementation class to the JAXBContext. We also have to look into resetting the $$_isNew flag as all creatable+updatable instances will have that set, regardless if it has an id attribute or not. We also need an id accessor contract like for jackson.
I think it shouldn't be a big problem to generate annotations into the proxy implementation classes and an ObjectFactory class that is responsible for creating entity view instances. The ObjectFactory class we would need to generate contains a static volatile field for the
EntityViewManager
and static factory methods for all entity view types. The methods simply create instances by passing theEntityViewManager
, essentially whatEntityViewManager.create()
is doing as well.The entity view proxy classes then also get a
@XmlType(factoryClass = ObjectFactory.class, factoryMethod = "createXYZ")
annotation(fill with values from super class), the rest should be configurable via the parent class/interface that the user provides. The JAXBContext should be somehow cached. I guess this could be the start of an entity view extension/integration module, or we keep it implementation private for now, but already pluggable. Keep in mind that this should be deactivatable to avoid possible issues on newer JDKs.We should note in the documentation that interfaces/abstract classes, shouldn't be annotated with
XmlRootElement
as that seems to lead to errors with the Sun implementation. If that is something that we really need, we will probably have to introduce a new annotation that leads to theXmlRootElement
annotation to be added to the implementation class.