-
Notifications
You must be signed in to change notification settings - Fork 99
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
CopyablePlugin does not copy empty lists --> invalid XML #576
Comments
Thanks for your report. Could you join MRE (Minimal Reproducible Example) so we can dig in more the process behind this issue ? My first guess would be that on |
…blem when copyTo copies empty lists as null
Hi @laurentschoelens, thanks for reacting to my issue! |
My guess is it's more related to jaxb marshalling on null attributes list rather than copyable plugin issue. Depending on setting the following line in comment or not : FooElement element = new FooElement();
// element.getBarAttribute().clear(); You'll get a failing (commented) or passing (uncommented) test result on marshalling to XML since by default, barAttribute is null. |
@laurentschoelens you don't even need // GIVEN XML is <FooElement BarAttribute=""/>
// WHEN unmarshalling, copyTo() (or clone()), marshalling
// THEN the XML is <FooElement/> |
I need to dig more into this to check what happens on elements point of view (vs. Attributes) |
Cf. related issue eclipse-ee4j/jaxb-ri#1823
Unfortunately, the CopyablePlugin does not copy empty lists. This behavior may lead to invalid XML, if the XML Schema specifies a mandatory attribute (
use="required"
) of list type with no restriction on the list's size - i.e., an XML document with the attribute being present but empty validates successfully, while an XML dockument lacking the attribute fails validation against the schema.As the CopyablePlugin does not copy empty lists from attributes, a valid XML document (with an empty attribute of list type) becomes invalid when unmarshalled, copied, and marshalled again.
AFAIU, the problem originates from the implementation of jaxb-ri's
AbstractListField.Accessor.hasSetValue()
. This is used twice in jaxb-tools:I do understand that lists of XML elements do not have the same problem (empty lists and "null" lists of XML elements are indistinguishable). So this problem really only applies to lists in XML attributes.
I would be interested to hear your opinion. Do you follow my argument that this is a bug? How could this be solved? Should lists from XML elements be treated differently than lists from XML attributes? If so, what could be done to achieve this?
Thanks in advance!
The text was updated successfully, but these errors were encountered: