[JAXB-758] Wrong behaviour with xsd:any and a payload with default namespace Created: 19/May/10  Updated: 18/Sep/13

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: cistox Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 758


I am working with Metro 2.1 nightly, JAXB 2.2 and WS-Transfer.
WS-Transfer elements like Put, Create, ... are providing an xsd:any content
where I need to add the original payload to be transferred.
Actually JAXB is erroneously modifying the namespace of a payload with default

xsd:Any allows almost any content and expecially using skip processing such
content must be ignored.
There is no reason to add the outer namespace (e.g. the namespace of a
ws-transfer "Put" element) to the inner payload.

Payload's integrity is required to be preserved as it could represent an Invoice
with an incorporated digital signature.
This means the receiver must be able to validate the signature against the
payload content (and this is not possible if the payload is modified on-the-road).
The transport should not change the payload at all...

Actually I noted that JAXB has a strange behaviour with either "lax" and "skip"
processing of the xsd:any if the payload has a default namespace declared into
its root (xmlns="...").

Example using LAX or SKIP processing
Generated by JAXB:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="" xmlns:ns4="[WS-Transfer NS]" xmlns="[original default NS]" />

This is how it should be with the original payload:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="[original default NS]"/>

I believe that xsd:Any "skip" processing should completely ignore the xml
content and thus the way namespaces are declared in the payload should be

The same is for "lax" processing if the payload is not using elements from
declared namespaces in the context (as it is usually for a business payload).

Example using <jaxb:dom/> xs:annotation
I made this exercise to avoid a dependancy between Put and its xs:any content.
I dreamed to see the payload untouched after this change but I was wrong.

<xs:element name="Put">
<xs:any minOccurs="1" maxOccurs="unbounded" namespace="##other"
<xs:anyAttribute namespace="##other" processContents="lax" />

Generated by JAXB:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice:Invoice xmlns:Invoice="[original default NS]" xmlns:ns4="[WS-Transfer
NS]" xmlns="[original default NS]" />

NOTE: The behaviour is changed a few here, but the namespace "xmlns:Invoice" is
really undesired and not useful at all.

This is how the Put should be with the original payload:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="[original default NS]"/>

Payloads with a default namespace are a common case, I really hope this is not a
real limit of JAXB.

Please can you suggest a workaround ?

Thank you in advance for any help

Best regards

Roberto Cisternino

Comment by cistox [ 19/May/10 ]

The following thread and issue are related:

Namespace error when marshalling DOM element with attributes using JAXB 2.1


Comment by Pavel Bucek [ 19/May/10 ]

adjusting priority (P1 is showstopper)

we know about this but its very hard to fix anything regarding namespaces (because of our thorough test
suites and regressions from dependent products). additionally, this is not "wrong", its valid xml.
Namespaces are there because of unpredictability of xsd:any content.

Comment by Martin Grebac [ 06/Oct/10 ]


Comment by bshrom [ 17/May/12 ]

While this is a valid xml, this bug causes XML signature failure and eventually interoperability problem in Metro.
Metro/WSIT uses JAXB under the hood and when security tokens are included, located under xsd:any, they are modified before they go on the wire.
See related bug: http://java.net/jira/browse/METRO-16
The same problem is with OnBehalfOf when SAML Assertion token is used, which breaks WS-Trust interoperability between Metro and .NET.
MS .NET uses xmlns="[original default NS]" constructs all the time resulting in modified XML and signature failure.

This bug should've never been classified as Improvement.

Comment by cistox [ 31/May/12 ]

It is incredible the JAXB 758 bug is still there. The way xsd:Any is handled is wrong. There is no reason to add namespaces from the outer envelope (e.g. WS-Transfer scaffolding) on the xsd:Any content.

Primary European projects are suffering of these bugs, it is very bad that such fixes are not applied due to dependancies from other bugged projects...
I am curious to know one of these projects that is relying on such JAXB bugs for its functions. It's a crazy situation.

XML is a nice thing but it's happen is going to be used on real business scenarios... thus digital signatures and other most serious dependancies have to be supported...

Comment by cistox [ 17/May/13 ]

Dear all,
major European projects like PEPPOL are going to fail using the actual Metro stack due to such JAXB issues.
All the project is moving to AS2 due to the interop issues with .NET.

I am really curious why JAXB cannot be fixed about the xsd:Any behaviour... I do not think other software can take any benefit from such wrong behaviour.

Comment by cistox [ 29/May/13 ]


The actual way the xsd:Any is handled by JAXB is not conformant to W3C XML Schema.

My proposal is to introduce a switch to let the developer to use JAXB in a conformant way and another to play the actual version (let's give it a name to justify its existance...)

With this basic switch the actual dependancies will be safe, but those interested into a conformat behaviour of xsd:Any will be really happy.

At this stage WS-Transfer and SAML have been identified as suffering from this bug when implemented using JAXB, but I am pretty sure this bug is the cause of several other issues. For instance the digital signature applied to a payload could be compromised by the addition of unwanted namespaces.

Hope this helps.

Comment by fontana.damiano [ 18/Sep/13 ]

we are experimenting the same issue described above.
We hope that it will be fixed as soon as possible, in order to successufully use JAXB in enterprise B2B solutions to exchange document of any type in XML format

Generated at Sun Nov 29 21:46:12 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.