jaxb
  1. jaxb
  2. JAXB-758

Wrong behaviour with xsd:any and a payload with default namespace

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: not determined
    • Component/s: runtime
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      758

      Description

      Hello,
      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
      namespace.

      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]" />
      </ns4:Put>

      This is how it should be with the original payload:

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

      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
      untouched...

      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:complexType>
      <xs:sequence>
      <xs:any minOccurs="1" maxOccurs="unbounded" namespace="##other"
      processContents="skip">
      <xs:annotation><xs:appinfo>
      <jaxb:dom/>
      </xs:appinfo></xs:annotation>
      </xs:any>
      </xs:sequence>
      <xs:anyAttribute namespace="##other" processContents="lax" />
      </xs:complexType>
      </xs:element>

      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]" />
      </ns4:Put>

      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]"/>
      </ns4:Put>

      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

        Activity

        cistox created issue -
        Hide
        cistox added a comment -

        The following thread and issue are related:

        Namespace error when marshalling DOM element with attributes using JAXB 2.1
        http://forums.java.net/jive/thread.jspa?threadID=55699&tstart=0

        Issue
        https://jaxb.dev.java.net/issues/show_bug.cgi?id=585

        Show
        cistox added a comment - The following thread and issue are related: Namespace error when marshalling DOM element with attributes using JAXB 2.1 http://forums.java.net/jive/thread.jspa?threadID=55699&tstart=0 Issue https://jaxb.dev.java.net/issues/show_bug.cgi?id=585
        Hide
        Pavel Bucek added a comment -

        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.

        Show
        Pavel Bucek added a comment - 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.
        Hide
        Martin Grebac added a comment -

        updating

        Show
        Martin Grebac added a comment - updating
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 758 28843
        Hide
        bshrom added a comment -

        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.

        Show
        bshrom added a comment - 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.
        Hide
        cistox added a comment -

        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...

        Show
        cistox added a comment - 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...
        Martin Grebac made changes -
        Assignee Martin Grebac [ snajper ] Iaroslav Savytskyi [ yaroska ]
        Hide
        cistox added a comment -

        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.

        Show
        cistox added a comment - 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.
        Hide
        cistox added a comment -

        HOW TO SOLVE THIS ISSUE:

        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.

        Show
        cistox added a comment - HOW TO SOLVE THIS ISSUE: 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.
        Hide
        fontana.damiano added a comment -

        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

        Show
        fontana.damiano added a comment - 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

          People

          • Assignee:
            Iaroslav Savytskyi
            Reporter:
            cistox
          • Votes:
            5 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: