ODE
  1. ODE
  2. ODE-664

Namespace declarations not being copied in ASSIGN.replaceElement

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3.3, 1.3.4
    • Fix Version/s: 1.3.6, 1.4
    • Component/s: BPEL Runtime
    • Labels:

      Description

      The following line in ASSIGN.replaceElement looks wrong:

      DOMUtils.copyNSContext(ptr, replacement);

      I think it should be:

      DOMUtils.copyNSContext(src, replacement);

      The rationale is that the RE strategy should copy the attributes from the source element to the target element. Without this change, you may end up with undeclared namespace prefixes in the output of your BPEL.

      1. XMLNamespaces.patch
        8 kB
        Karolis Petrauskas
      2. HelloWorld2.zip
        12 kB
        Mark Ford

        Activity

        Hide
        Hudson added a comment -

        Integrated in ODE-1.x #195 (See https://builds.apache.org/job/ODE-1.x/195/)
        Karolis Petrauskas' patch for ODE-664 applied. (Revision ce94ea8f7f98551185df169c6960963023b18735)

        Result = SUCCESS
        vanto :
        Files :

        • utils/src/main/java/org/apache/ode/utils/DOMUtils.java
        • bpel-test/src/test/resources/bpel/2.0/TestInsertMissingData/test1.properties
        • bpel-test/src/test/resources/bpel/2.0/TestSubTreeAssign/test1.properties
        • bpel-epr/src/main/java/org/apache/ode/il/OMUtils.java
        • bpel-test/src/test/resources/bpel/2.0/TestXPathNamespace1/test1.properties
        • bpel-test/src/test/resources/bpel/2.0/ExtVar-GenKey/test.properties
        • bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/ASSIGN.java
        Show
        Hudson added a comment - Integrated in ODE-1 .x #195 (See https://builds.apache.org/job/ODE-1.x/195/ ) Karolis Petrauskas' patch for ODE-664 applied. (Revision ce94ea8f7f98551185df169c6960963023b18735) Result = SUCCESS vanto : Files : utils/src/main/java/org/apache/ode/utils/DOMUtils.java bpel-test/src/test/resources/bpel/2.0/TestInsertMissingData/test1.properties bpel-test/src/test/resources/bpel/2.0/TestSubTreeAssign/test1.properties bpel-epr/src/main/java/org/apache/ode/il/OMUtils.java bpel-test/src/test/resources/bpel/2.0/TestXPathNamespace1/test1.properties bpel-test/src/test/resources/bpel/2.0/ExtVar-GenKey/test.properties bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/ASSIGN.java
        Hide
        Hudson added a comment -

        Integrated in ODE-trunk-jdk6 #486 (See https://builds.apache.org/job/ODE-trunk-jdk6/486/)
        Karolis Petrauskas' patch for ODE-664 applied. (Revision 5b052ce9f0c55b80b5b41d3d6f410c2b0d95c402)

        Result = UNSTABLE
        vanto :
        Files :

        • bpel-test/src/test/resources/bpel/2.0/TestXPathNamespace1/test1.properties
        • utils/src/main/java/org/apache/ode/utils/DOMUtils.java
        • bpel-epr/src/main/java/org/apache/ode/il/OMUtils.java
        • bpel-test/src/test/resources/bpel/2.0/TestSubTreeAssign/test1.properties
        • bpel-test/src/test/resources/bpel/2.0/TestInsertMissingData/test1.properties
        • bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/ASSIGN.java
        • bpel-test/src/test/resources/bpel/2.0/ExtVar-GenKey/test.properties
        Show
        Hudson added a comment - Integrated in ODE-trunk-jdk6 #486 (See https://builds.apache.org/job/ODE-trunk-jdk6/486/ ) Karolis Petrauskas' patch for ODE-664 applied. (Revision 5b052ce9f0c55b80b5b41d3d6f410c2b0d95c402) Result = UNSTABLE vanto : Files : bpel-test/src/test/resources/bpel/2.0/TestXPathNamespace1/test1.properties utils/src/main/java/org/apache/ode/utils/DOMUtils.java bpel-epr/src/main/java/org/apache/ode/il/OMUtils.java bpel-test/src/test/resources/bpel/2.0/TestSubTreeAssign/test1.properties bpel-test/src/test/resources/bpel/2.0/TestInsertMissingData/test1.properties bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/ASSIGN.java bpel-test/src/test/resources/bpel/2.0/ExtVar-GenKey/test.properties
        Hide
        Karolis Petrauskas added a comment -

        Fix for disapearing namespaces.

        Show
        Karolis Petrauskas added a comment - Fix for disapearing namespaces.
        Hide
        Tammo van Lessen added a comment -

        confirmed. Especially loosing the ns2 prefix scares me.

        Show
        Tammo van Lessen added a comment - confirmed. Especially loosing the ns2 prefix scares me.
        Hide
        Mark Ford added a comment -

        Attached is a modified version of the HelloWorld2 example process to illustrate this defect. The changes here are fairly extensive since I had to add an XSD and change the WSDL bindings to doc/literal so I could send/receive elements although it's still a simple process.

        I don't recall exactly what I was attempting to do in the original process definition that prompted me to look at the ASSIGN code and report this issue. I do know that I was constructing elements with XQuery and relying on the Replace Element strategy from the spec to propagate namespace declarations where needed.

        In the attached test case, you get the following response from the sendsoap driver:

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
           <soapenv:Body>
              <parent xmlns="urn:schema:one">
                 <child xmlns="">ns2:hello</child>
              </parent>
           </soapenv:Body>
        </soapenv:Envelope>
        

        Please note that the element named "child" is in the empty namespace when it should be in the urn:schema:two namespace. Also note that there is no namespace declaration for ns2 on the child element which is a problem since its text value references that namespace (in an application specific manner). See the attached bpel for details. I believe that the behavior has changed from my original report but the above is still incorrect. Please disregard my original suggestion to change the specified line of code in ASSIGN. I'm sure a lot has changed since the original report.

        Show
        Mark Ford added a comment - Attached is a modified version of the HelloWorld2 example process to illustrate this defect. The changes here are fairly extensive since I had to add an XSD and change the WSDL bindings to doc/literal so I could send/receive elements although it's still a simple process. I don't recall exactly what I was attempting to do in the original process definition that prompted me to look at the ASSIGN code and report this issue. I do know that I was constructing elements with XQuery and relying on the Replace Element strategy from the spec to propagate namespace declarations where needed. In the attached test case, you get the following response from the sendsoap driver: <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" > <soapenv:Body> <parent xmlns= "urn:schema:one" > <child xmlns=""> ns2:hello </child> </parent> </soapenv:Body> </soapenv:Envelope> Please note that the element named "child" is in the empty namespace when it should be in the urn:schema:two namespace. Also note that there is no namespace declaration for ns2 on the child element which is a problem since its text value references that namespace (in an application specific manner). See the attached bpel for details. I believe that the behavior has changed from my original report but the above is still incorrect. Please disregard my original suggestion to change the specified line of code in ASSIGN. I'm sure a lot has changed since the original report.
        Hide
        David Carver added a comment -

        Mark I'm assuming from your example:

        <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2">
        <ns2:sourceChild/>
        </ns1:sourceNode>

        Should actually be:

        <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns2="namespace2">
        <ns2:sourceChild/>
        </ns1:sourceNode>

        As there is an extra : in the declaration for the second namespace.

        Show
        David Carver added a comment - Mark I'm assuming from your example: <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2"> <ns2:sourceChild/> </ns1:sourceNode> Should actually be: <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns2="namespace2"> <ns2:sourceChild/> </ns1:sourceNode> As there is an extra : in the declaration for the second namespace.
        Hide
        Mark Ford added a comment -

        I am interested in the first bullet point as you correctly quoted from Section 8.4.2 of WS-BPEL 2.0.

        "Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties."

        Full stop, no need to proceed further since the remaining bits are about keepSrcElementName.

        For example:

        Copying:

        <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2">
        <ns2:sourceChild/>
        </ns1:sourceNode>

        To:

        <ns3:targetNode xmlns:ns3="namespace3" xmlns:ns4="namespace4">
        <ns4:targetChild/>
        </ns3:targetNode>

        Should result in:

        <ns3:targetNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2" xmlns:ns3="namespace3">
        <ns2:sourceChild/>
        </ns3:targetNode>

        But in ODE it results in:

        <ns3:targetNode xmlns:ns3="namespace3">
        <ns2:sourceChild/>
        </ns3:targetNode>

        The problem with the result in ODE is that it is missing the namespace declaration for <ns2:sourceChild>. This will cause problems when trying to parse the xml again. I ran into this exact issue and it took me a while to figure out where it was going wrong since I'm running ServiceMix and wasn't sure if the problem was in there or ODE.

        To be fair, my original report above has no context or additional info for which I apologize. I'm pressed for time and banged out a few bugs while trying to get my app to work. I'll spend the extra couple of minutes next time to put together something more coherent, although a patch with unit tests isn't likely coming soon.

        If you look at the replaceElement code in ASSIGN, you'll see that it skips over the namespace decls for the source node. It relies on a util method call below to copy the namespace decl from the target node onto the replacementElement. If you look at the history of the file, there was a change made to skip over the namespace declarations back in 2008 although I don't understand why.

        My comment about the copying namespace declarations over from the to-spec onto the replacementElement being a violation of the RE strategy were secondary to the real bug which is not copying the source decls over. By copying over all of the namespace decls from the to-spec to the replacementElement you're doing something that isn't specified and in fact may inadvertently be changing the element's meaning. Not having looked at the namespace context propagation code, I'm not sure how it handles namespace collisions or encoded namespaces within text or CDATA but even if it worked perfectly, it seems unnecessary – although again, a subtle issue which is minor in comparison to the original problem.

        Show
        Mark Ford added a comment - I am interested in the first bullet point as you correctly quoted from Section 8.4.2 of WS-BPEL 2.0. "Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties." Full stop, no need to proceed further since the remaining bits are about keepSrcElementName. For example: Copying: <ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2"> <ns2:sourceChild/> </ns1:sourceNode> To: <ns3:targetNode xmlns:ns3="namespace3" xmlns:ns4="namespace4"> <ns4:targetChild/> </ns3:targetNode> Should result in: <ns3:targetNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2" xmlns:ns3="namespace3"> <ns2:sourceChild/> </ns3:targetNode> But in ODE it results in: <ns3:targetNode xmlns:ns3="namespace3"> <ns2:sourceChild/> </ns3:targetNode> The problem with the result in ODE is that it is missing the namespace declaration for <ns2:sourceChild>. This will cause problems when trying to parse the xml again. I ran into this exact issue and it took me a while to figure out where it was going wrong since I'm running ServiceMix and wasn't sure if the problem was in there or ODE. To be fair, my original report above has no context or additional info for which I apologize. I'm pressed for time and banged out a few bugs while trying to get my app to work. I'll spend the extra couple of minutes next time to put together something more coherent, although a patch with unit tests isn't likely coming soon. If you look at the replaceElement code in ASSIGN, you'll see that it skips over the namespace decls for the source node. It relies on a util method call below to copy the namespace decl from the target node onto the replacementElement. If you look at the history of the file, there was a change made to skip over the namespace declarations back in 2008 although I don't understand why. My comment about the copying namespace declarations over from the to-spec onto the replacementElement being a violation of the RE strategy were secondary to the real bug which is not copying the source decls over. By copying over all of the namespace decls from the to-spec to the replacementElement you're doing something that isn't specified and in fact may inadvertently be changing the element's meaning. Not having looked at the namespace context propagation code, I'm not sure how it handles namespace collisions or encoded namespaces within text or CDATA but even if it worked perfectly, it seems unnecessary – although again, a subtle issue which is minor in comparison to the original problem.
        Hide
        Karthick Sankarachary added a comment -

        Maybe we're talking about different things here. Can you indicate the violation in the RE strategy that is described below?

        RE (Replace-Element-properties):

        o Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties.

        An optional keepSrcElementName attribute is provided to further refine the behavior. [SA00042] It is only applicable when the results of both from-spec and to-spec are EIIs, and MUST NOT be explicitly set in other cases. A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:selectionFailure fault MUST be thrown.

        § When the keepSrcElementName attribute is set to "no", the name (i.e. [namespace name] and [local name] properties) of the original destination element is used as the name of the resulting element. This is the default value.

        § When the keepSrcElementName attribute is set to "yes", the source element name is used as the name of the resulting destination element.

        When the keepSrcElementName attribute is set to "yes" and the destination element is the Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, a WS-BPEL processor MUST make sure the name of the source element belongs to the substitutionGroup of the destination element used in the element variable declaration or WSDL part definition. The substitutionGroup relation is determined by XML Schemas known to the WS-BPEL processor. [SA00094] A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:mismatchedAssignmentFailure fault MUST be thrown.

        Show
        Karthick Sankarachary added a comment - Maybe we're talking about different things here. Can you indicate the violation in the RE strategy that is described below? RE (Replace-Element-properties): o Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties. An optional keepSrcElementName attribute is provided to further refine the behavior. [SA00042] It is only applicable when the results of both from-spec and to-spec are EIIs, and MUST NOT be explicitly set in other cases. A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:selectionFailure fault MUST be thrown. § When the keepSrcElementName attribute is set to "no", the name (i.e. [namespace name] and [local name] properties) of the original destination element is used as the name of the resulting element. This is the default value. § When the keepSrcElementName attribute is set to "yes", the source element name is used as the name of the resulting destination element. When the keepSrcElementName attribute is set to "yes" and the destination element is the Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, a WS-BPEL processor MUST make sure the name of the source element belongs to the substitutionGroup of the destination element used in the element variable declaration or WSDL part definition. The substitutionGroup relation is determined by XML Schemas known to the WS-BPEL processor. [SA00094] A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:mismatchedAssignmentFailure fault MUST be thrown.
        Hide
        Mark Ford added a comment -

        Also, I didn't mention it before but I am not using "keepSrcElement"

        Show
        Mark Ford added a comment - Also, I didn't mention it before but I am not using "keepSrcElement"
        Hide
        Mark Ford added a comment -

        I didn't attach a test case but will put one together when my project is done in a few weeks.

        You are not copying the namespace declarations over. Please review the code and notice that the namespace declarations are explicitly skipped over in the for loop above and then never put on the target.

        As for copying the namespace decls over from the to-spec, that's a violation of the RE strategy.

        Show
        Mark Ford added a comment - I didn't attach a test case but will put one together when my project is done in a few weeks. You are not copying the namespace declarations over. Please review the code and notice that the namespace declarations are explicitly skipped over in the for loop above and then never put on the target. As for copying the namespace decls over from the to-spec, that's a violation of the RE strategy.
        Hide
        Karthick Sankarachary added a comment -

        We do adhere to the RE (replace-element-properties) rule that requires us to "replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties.", as you tell by looking at the calls to "importNode" that precede that line.

        The line you are referring to ensures that the namespaces defined in the to-spec carry over to the copy of the target element that we create in ASSIGN.replaceElement.

        Show
        Karthick Sankarachary added a comment - We do adhere to the RE (replace-element-properties) rule that requires us to "replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties.", as you tell by looking at the calls to "importNode" that precede that line. The line you are referring to ensures that the namespaces defined in the to-spec carry over to the copy of the target element that we create in ASSIGN.replaceElement.

          People

          • Assignee:
            Tammo van Lessen
            Reporter:
            Mark Ford
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development