-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different behaviour of (un)marshaller vs JAXB reference implementation #84
Comments
sorry, missed this ... |
I believe the interpretation of The "Ant Task Example" in the JAXB documentation shows that the property name itself (in this example
vs
I am investigating how best to fix. |
@manstis correct me if i am wrong, looks like the fix is just processing the collection, annotated with @XMLElementRefs as XmlUnwrappedCollection ? so pitty, can't use XmlElementRef because we need to know all subtypes of annotated field to generate (de)marshallers, so only XmlElementRefs left
|
Well, it all depends whether To be honest I was thinking to propose the removal of I can easily add Can you explain why |
I do have another problem where an attempt to deserialise a property is being made by the wrong deserializer. If run my webapp and click the "Load XML" button the following error is thrown:
The chain of deserialisers is:
POJO
XML
POJO
XML
POJO
XML
POJO
XML
As you can see; I have a |
@manstis thanks you for your detailed report, i am working on it right now. |
@XmlElements is also must be fixed ... |
@treblereel I checked out your branch and built locally. Unfortunately my "PMML" model still presents the |
Mirrored this on https://issues.redhat.com/browse/KOGITO-5457. Please continue the discussions here. |
@manstis ok, one moment plz ... |
@manstis hmm, no exception
with branch @XmlElementRefs_fix |
If I run the equivalent in the JRE using the JAXB reference implementation, it works fine:
This therefore remains an issue with the |
BTW, it's the unmarshalling that is failing; not the marshalling. See the JAXB RI equivalent here. |
@manstis here is marshalling -> unmarshalling->marshalling -> unmarshalling it doesn't throw an exception
ps: it's not a master, it's branch @XmlElementRefs_fix |
Yes, I know it's on the branch @treblereel. Can you try the whole PMML file I am using and not just the |
yeap, sure |
@treblereel FYI, I've re-checked I'm using the correct |
@manstis i have added PMMLTest.java based on your pmml beans, no exception :( May i ask you to attach your xml ? |
@treblereel Sure, I appreciate your time investigating. It is available here. |
It unmarshals fine using JAXB's Reference Implementation. |
@treblereel The XML produced from the generated marshallers is wrong:
Please note the double
|
@manstis you were right, my collection (de)ser is wrong, so i reimplemented it to be more jaxb compatible. so remarshalled https://raw.githubusercontent.com/manstis/marshaller/main/marshaller-jre/src/main/resources/jaxb/pmml.xml is:
|
and yeah, @XmlUnwrappedCollection is totally useless and must me eliminated |
Hi @treblereel I can confirm your changes in #85 resolve the issues I've reported. Many thanks. I have some other issues now but I will investigate what may be causing them (if I marshal the classes to XML I am getting quite a few attributes set that were not in the original XML). IDK whether it's an unmarshalling or marshalling issue at the moment; or even something else. I'll investigate and let your know. For now, please feel free to merge #85, resolve this issue and close https://issues.redhat.com/browse/KOGITO-5457. |
I was trialling the XML (un)marshallers generated by the
@XMLMapper
annotation.The issues below do not exist when using the JAXB reference implementation in a normal JRE.
You can clone/fetch https://github.com/manstis/marshaller to see the behaviours:
marshaller-api
contains the annotated POJO model classes (generated from XSD)marshaller-client
andmarshaller-server
are the GWT webapp; run it (see README) and press the buttons.marshaller-jre
deserialises and serialises the XML using the same POJOs but JAXB reference implementation.The issues are:
Deserialisation
The deserialisation does not work correctly for
@JAXBElementRefs
. It can be made to work with the inclusion of the@XmlUnwrappedCollection
annotation on collections however cases that are not collections fail to de-serialise. Furthermore use of the ofXmlUnwrappedCollection
should not be necessary (as it is not needed by the JAXB reference implementation).Model class
Generated code
(Compare this to how it works for collections with the
@XmlUnwrappedCollection
annotation. Deserialisation fails as the generated code fails to find a deserialiser forSimplePredicate
as only a deserialiser forpredicate
has been registered).XML
Serialisation
Generation of the serialisers does not seem to consider use of
@JAXBElementRefs
at all and the resulting XML does not have element names matching the sub-class names listed in the separate@JAXBElementRef
annotations. For example anAttribute
POJO (from above) withICompoundPredicate predicate
property equal to an instance ofSimplePredicate
should have the XML from serialisation as<SimplePredicate ..../>
(also as above).The text was updated successfully, but these errors were encountered: