ODE
  1. ODE
  2. ODE-371

Auto Complete Copy Destination (L-Value)

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.3.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      platform-independent

      Description

      A lot of times, users expect the <copy> operation in a WS-BPEL assign activity to behave such that the path specified by the destination ("to-spec") is automatically created, if it doesn't already exist. By default, if the to-spec used within a <copy> operation does not select exactly one XML information item during execution, then the standard fault bpel:selectionFailure is thrown (as mandated by the spec).

      To override this default behavior, we introduce a insertMissingToData attribute in the <copy> operation, which if it is set to "yes", will instruct the runtime to complete the (XPath) L-value specified by the to-spec, if no items were selected. For the sake of simplicity, we will complete the to-spec if and only if:
      a) It's a path expression whose steps are separated by "/", and
      b) Its steps have an axis, which is either "child" or "attribute", and
      c) Its steps have no following predicates, and
      d) Its steps test the name of a node, without the use of wildcards.

      Formally, the grammar of the to-spec, for which auto-complete is enabled, may be defined in terms of these productions:
      PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr
      RelativePathExpr ::= ForwardStep (("/" ) ForwardStep)*
      ForwardStep ::= (ForwardAxis QName) | AbbrevForwardStep
      AbbrevForwardStep ::= "@"? QName
      ForwardAxis ::= ("child" "::") | ("attribute" "::")

      The example below illustrates the use of the insertMissingToData attribute. Let's say that the variable "response" is uninitialized. In that case, the first <copy> operation will fail, whereas the second one will succeed.

      <copy>
      <from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from>
      <to>$response/typeIndicators/types:indicatorTwo</to>
      </copy>

      <copy insertMissingToData="yes">
      <from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from>
      <to>$response/typeIndicators/child::types:indicatorTwo</to>
      </copy>

      Best Regards,
      Karthick Sankarachary

        Activity

        Hide
        Karthick Sankarachary added a comment -

        The patch has been applied on the trunk at revision 709057.

        Show
        Karthick Sankarachary added a comment - The patch has been applied on the trunk at revision 709057.
        Hide
        Karthick Sankarachary added a comment -

        The patch has been applied on the 1.X branch at revision 709010.

        Show
        Karthick Sankarachary added a comment - The patch has been applied on the 1.X branch at revision 709010.
        Hide
        Karthick Sankarachary added a comment -

        The revised patch (a) propogates the "insertMissingToData" property through OLValueExpression instead of the EvaluationContext and (b) defines a new feature-specific test case.

        Show
        Karthick Sankarachary added a comment - The revised patch (a) propogates the "insertMissingToData" property through OLValueExpression instead of the EvaluationContext and (b) defines a new feature-specific test case.
        Hide
        Matthieu Riou added a comment -

        A couple of observations about the patch:

        • The information about whether we're in an insertMissingToData should be added to the OExpression of the lvalue instead of adding this callback on EvaluationContext for runtime access. It's only used in a particular case of evaluation so you end up with several dummy implementations of isInsertMissingData for no real good reasons. It's not really the role of this interface.
        • Could you create a separate test case instead of reusing TestSubTreeAssign.bpel yet again? I don't mind you cloning it and removing the non relevant parts, it's just that more focused test cases are easier for diagnostic and to maintain, especially when they test extensions.

        Thanks!

        Show
        Matthieu Riou added a comment - A couple of observations about the patch: The information about whether we're in an insertMissingToData should be added to the OExpression of the lvalue instead of adding this callback on EvaluationContext for runtime access. It's only used in a particular case of evaluation so you end up with several dummy implementations of isInsertMissingData for no real good reasons. It's not really the role of this interface. Could you create a separate test case instead of reusing TestSubTreeAssign.bpel yet again? I don't mind you cloning it and removing the non relevant parts, it's just that more focused test cases are easier for diagnostic and to maintain, especially when they test extensions. Thanks!

          People

          • Assignee:
            Karthick Sankarachary
            Reporter:
            Karthick Sankarachary
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 168h
              168h
              Remaining:
              Remaining Estimate - 168h
              168h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development