[
https://issues.apache.org/jira/browse/ODE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038115#comment-13038115
]
tbuss edited comment on ODE-922 at 5/23/11 6:38 PM:
----------------------------------------------------
I have a proposed fix for this issue.
To fixing the ODE compiler to allow <from> ... literal value ... </from> modify
the From class to fix up literal values for BPEL 1.1 following the similar
technique used for expressions...
public LiteralVal getAsLiteralVal() {
// BPEL 1.1 fixups. In 1.1 a literal was the value of the <from>
element not the value of a child <literal> element.
if (is11()) {
String literalText = getTextValue();
return literalText == null ? null : new LiteralVal11( getElement());}
else {
return getFirstChild(LiteralVal.class);
}
}
and then provide a class that represent the BPEL 1.1 literal.
public class LiteralVal11 extends LiteralVal {
public LiteralVal11(Element el) {
//This will be a <From> element not a <Literal> element
//This subclass may not be necessary
//It is here only to distinguish the 1.1 to 2.0 difference
super(el);
}
}
The only purpose of this class, LiteralVal11, is to indicate there is a
difference between 1.1 and 2.0. It has no other behavior and is not essential
to the fix. The main thing to note is that instead of the <literal> element
that contains the text value of the literal in BPEL 2.0, this class will hold
a <from> element that contains the text value of the literal. The class files
and compiled .jar are attached.
Note: I have tested this with various examples and it seems to address the
issue without causing problems. I wrote a unit test but the current ODE
compiler uint test structure is oriented to testing things that are supposed to
fail which makes it difficult to supply a unit test for something that is
supposed to work.
was (Author: tbuss):
I have a proposed fix for this issue.
To fixing the ODE compiler to allow <from> ... literal value ... </from> modify
the From class to fix up literal values for BPEL 1.1 following the similar
technique used for expressions...
public LiteralVal getAsLiteralVal() {
// BPEL 1.1 fixups. In 1.1 a literal was the value of the <from>
element not the value of a child <literal> element.
if (is11()) {
String literalText = getTextValue();
return literalText == null ? null : new LiteralVal11( getElement());}
else {
return getFirstChild(LiteralVal.class);
}
}
and then provide a class that represent the BPEL 1.1 literal.
public class LiteralVal11 extends LiteralVal {
public LiteralVal11(Element el) {
//This will be a <From> element not a <Literal> element
//This subclass may not be necessary
//It is here only to distinguish the 1.1 to 2.0 difference
super(el);
}
}
The only purpose of this class, LiteralVal11, is to indicate there is a
difference between 1.1 and 2.0. It has no other behavior and is not essential
to the fix. The main thing to note is that instead of the <literal> element
that contains the text value of the literal in BPEL 2.0, this class will hold
a <from> element that contains the text value of the literal. The class files
and compiled .jar are attached.
> Problem with BPEL 1.1 literal initialization support
> ----------------------------------------------------
>
> Key: ODE-922
> URL: https://issues.apache.org/jira/browse/ODE-922
> Project: ODE
> Issue Type: Bug
> Components: BPEL Compilation/Parsing
> Affects Versions: 1.3.5
> Environment: Windows XP SP3, Tomcat-7.0.10, jdk1.6.0
> Reporter: tbuss
> Attachments: Ode_Compiler_Fix.zip
>
>
> I am trying to port some BPEL 1.1 workflows to ODE 1.3.5 but am having
> difficulty with assigning literal XML.
> According to all the discussions and specs for BPEL 1.1 I have found, the
> correct <from> syntax for literals is <from>some literal value</from>.
> In BPEL 2.0 this appears to have changed to
> <from><literal>...</literal></from> but <literal> is not defined for BPEL 1.1.
> For example, given the namespaces:
> xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/";
> xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/";
> and given a schema type:
> <xsd:schema targetNamespace="urn:MyNamespace" xmlns="urn:MyNamespace"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
> <xsd:complexType name="CredentialsType">
> <xsd:sequence>
> <xsd:element name="UsernameToken">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="Username" type="xsd:string" />
> <xsd:element name="Password" type="xsd:string" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:schema>
> The following BPEL should be valid:
> <variables>
> <variable name="myliteralvar" type="myns:CredentialsType"/>
> </variables>
> <assign name="assign1">
> <copy>
> <from >
> <myns:UsernameToken xmlns:myns="urn:MyNamespace">
> <myns:username xmlns:myns="urn:MyNamespace" />
> <myns:password xmlns:myns="urn:MyNamespace" />
> </myns:UsernameToken>
> </from>
> <to variable="myliteralvar"/>
> </copy>
> </assign>
> And result is the variable, myliteralvar taking the value
> <myns:UsernameToken xmlns:myns="urn:MyNamespace">
> <myns:username xmlns:myns="urn:MyNamespace" />
> <myns:password xmlns:myns="urn:MyNamespace" />
> </myns:UsernameToken>
> However Ode 1.3.5 complains on deployment with
> "Unrecognized element in BPEL dom: {urn:MyNamespace}UsernameToken"
> Followed by
> "error: [UnknownFromSpec] From-spec format is unrecognized.
> I have attached a full example where I modified the HelloWorld BPEL to use
> BPEL 1.1. It deploys successfully if the above assign is removed.
> Is this a known bug in Ode or is there some configuration apart from the BPEL
> namespace that is required to have Ode recognize BPEL 1.1 syntax?
> Note: I am setting the filename and bpel11wsdlFileName on the process element
> in deploy.xml
> <process name="pns:HelloWorld4"
> fileName="HelloWorld4.bpel"
> bpel11wsdlFileName="HelloWorld4.wsdl"
> >
> <active>true</active>
> <provide partnerLink="helloPartnerLink">
> <service name="wns:HelloService" port="HelloPort"/>
> </provide>
> </process>
> see user mailing list for original discussion and attachment
> http://mail-archives.apache.org/mod_mbox/ode-user/201104.mbox/%3c1B3A9CAA04782F40AC59576CFBFC802C0B22DE2B32@VA3DIAXVS251.RED001.local%3e
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
