As regards to checked in driver project
there are couple of issues with validation (not sure if i needed to use validation as component, used bpel-ui)
1. Contains an assigment of duration literal to xsd:time type. This should not be allowed and validation should catch
this as error. Currently, it flags this as warning and the project fails in the runtime.
<from>'P0Y0M0DT0H0M0S'</from><to part="timer" variable="Operation1In1"/>
2. It uses >= operator to do xsd time and duration comparisons. The following snippet from the BPEL compares timer
variable (type XSD:time) with duration value. This is not valid, the mapper should not allow this also validation should
flag this as error. Though this usage is invalid due to differing types, currently runtime does not support the equality
(=) or comparison operators (>, <, >=, <=) even if both sides are same type (time or duration).
<bpws:throw name="Throw1" faultName="ns1:fault1" faultVariable="Operation12Out1"/>
<condition> ( $Operation1In1.timer >= 'P0Y0M0DT0H0M20S' ) </condition>
project is RepeatUntilwithTime
fixed 1.: 4a86b807736b
Created attachment 61564 [details]
fixed 2.: eaff54005b9d
I suggested warning instead of error (there a lot of projects with this functionality).
I am not clear on the fix for 2. Would the validation return error for the dissimilar types or even same types if the
equality or comparison operator is used.
Verified with NetBeans IDE Dev (Build 200805211202).
The fix has been ported into the release61_fixes repository.
The fix rejects perfectly valid BPEL comparisons that have nothing to do with time or duration.
My application gets rejected for the following code, which is a string comparison of an attribute:
<condition>( $HTTPInvocationOperationOut.part1/@Decision = 'Permit' )</condition>
The rejection message is the following, which inspection of the source code suggests was intended to
be the fix for this issue:
ERROR: Currently runtime does not support the equality or comparison operators for time and duration types.
(I'm quoting the error message so that other people with the same problem can find it in issue searches.)
I suggest that either: (1) the check be made more sophisticated; or (2) this check be changed to a warning.
(Alternative 2 would still produce a very strange message, since the BPEL has nothing to do with time or duration,
but at least I could get my project to build without overriding validation.
Please provide the test project.
Created attachment 65819 [details]
Contains code that is incorrectly rejected
Created attachment 65820 [details]
Contains code that succeeds only because of double quotes
I've attached two project files to illustrate the problem. (I just realized that I messed up the MIME types on both
attachments, for which I apologize--if anyone has a means to fix this, please feel free to do so.)
Both files are slight modifications of a sample project(SOA/Blueprint1) that is delivered with NetBeans.
One of them is incorrectly rejected as a date-time condition; the other, even though it differs only in what
kind of quotation marks it uses, is accepted.
The original file contains the statement
What I did to make this fail was to change 'OrderVal' to 'P1=OrderVal'. The BPEL validator logic
is checking only two things:
1. The presence, anywhere in the condition, of a relational operator character, such as "="
2. The presence, anywhere in the condition, of a single quote, followed by an upper-case P, followed by a digit.
So by changing this literal to satisfy these criteria, I can make this project fail to build, even though the
logic clearly has nothing to do with time or duration.
To make it succeed again, all I had to do was to change the single quotes to double quotes, that is, to
represent the literal as "P1=OrderVal".
So I now understand that my original exampled failed simply because it contained "'P" (the condition that it
be followed by a decimal digit was apparently added in a later version of the validator--I am using NetBeans IDE 6.1
The fix would be to add a true parser for time literals, but I realize that this is a lot of work. And even if
such a change is implemented, it would still not cover two cases: (1) a literal that looks like a time literal
is being (legally) compared to a string; (2) two time variables, with no literals, are being (illegally) compared.
So my own recommendation, for what it's worth, would be to change this logic to a warning.
agree, I will change error to warning