You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We just switched to using com.sun.xml.ws:jaxws-ri:4.0.2 which uses org.eclipse.persistence:org.eclipse.persistence.core:4.0.2, instead of using com.sun.xml.bind:jaxb-impl:2.3.4
We try to unmarshal an object with a List of Object child (example below), so the unmarshalling creates an ElementNSImpl to create the inner Objects.
These inner objects have a different namespace compared to the rest of the test file
In the previous implementation we used, the "name" field of the ElementNSImpl was the fully qualified name (ns:nameOfField) whereas now, it's just the same as the localName field (nameOfField without the "ns:" part)
I got quite deep into debugguing and it turns out that we only unmarshal an inner node of the source file and the namespaces are defined on the higher level. (see test case below)
In the SAXFragmentBuilder class, the prefix is fetched afterwards using the owning record
int qNameColonIndex = qName.indexOf(Constants.COLON);
if ((namespaceURI != null) && (qNameColonIndex == -1)) {
//check for a prefix from the unmarshal record:
String prefix = owningRecord.resolveNamespaceUri(namespaceURI);
if (prefix != null && prefix.length() >0){
qName = prefix + Constants.COLON + qName;
qNameColonIndex = prefix.length();
}
}
but in our case, the prefix cannot be resolved since the namespaceMap used in StackUnmarshalNamespaceResolver is empty (since we did not unmarshal the part were the namespaces were defined)
but it feels akward to fetch the prefix from the map when it already is given on the node
My feeling is that the solution lies in the UnmarshalRecordImpl class, within the updateXPathFragment method :
In our case, we fall in the "else" part of the code since we have a namespaceURI that's not null and not blank, so the localName is set to localName and the namespaceURI to namespaceURI (which is normal) but it feels like we could use the prefix part of the xpathFragment : this.xPathFragment.setPrefix(extractPrefix(qName));
The code would then use the prefix set in the xPathFragment rather than resolving it : XMLAnyCollectionMappingNodeValue::startElement adds the prefix to the name when it was set on the xPathFragment, which is exactly what we expect in our case
Describe the bug
We just switched to using com.sun.xml.ws:jaxws-ri:4.0.2 which uses org.eclipse.persistence:org.eclipse.persistence.core:4.0.2, instead of using com.sun.xml.bind:jaxb-impl:2.3.4
We try to unmarshal an object with a List of Object child (example below), so the unmarshalling creates an ElementNSImpl to create the inner Objects.
These inner objects have a different namespace compared to the rest of the test file
In the previous implementation we used, the "name" field of the ElementNSImpl was the fully qualified name (ns:nameOfField) whereas now, it's just the same as the localName field (nameOfField without the "ns:" part)
I got quite deep into debugguing and it turns out that we only unmarshal an inner node of the source file and the namespaces are defined on the higher level. (see test case below)
In the SAXFragmentBuilder class, the prefix is fetched afterwards using the owning record
but in our case, the prefix cannot be resolved since the namespaceMap used in StackUnmarshalNamespaceResolver is empty (since we did not unmarshal the part were the namespaces were defined)
but it feels akward to fetch the prefix from the map when it already is given on the node
My feeling is that the solution lies in the UnmarshalRecordImpl class, within the updateXPathFragment method :
In our case, we fall in the "else" part of the code since we have a namespaceURI that's not null and not blank, so the localName is set to localName and the namespaceURI to namespaceURI (which is normal) but it feels like we could use the prefix part of the xpathFragment :
this.xPathFragment.setPrefix(extractPrefix(qName));
The code would then use the prefix set in the xPathFragment rather than resolving it :
XMLAnyCollectionMappingNodeValue::startElement
adds the prefix to the name when it was set on the xPathFragment, which is exactly what we expect in our caseTo Reproduce
Using Java 17 and org.eclipse.persistence:org.eclipse.persistence.core:4.0.2 (but previous versions seem to have the same issue)
Example test :
MyParentObject class :
test file (files/testBug.xml) :
Expected behavior
a fully qualified "name" field with the original namespace qualifier in the child ElementNsImpl object
The text was updated successfully, but these errors were encountered: