Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 135079 - Two issues with Validation - It fails to catch incorrect assignments and also time duration comparison
Two issues with Validation - It fails to catch incorrect assignments and also...
Product: soa
Classification: Unclassified
Component: BPEL Validation
All All
: P3 (vote)
: 6.x
Assigned To: Vladimir Yaroslavskiy
Depends on:
  Show dependency treegraph
Reported: 2008-05-14 19:42 UTC by malkit
Modified: 2008-07-29 14:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Test project (7.35 KB, application/x-compressed)
2008-05-19 14:27 UTC, Vladimir Yaroslavskiy
Contains code that is incorrectly rejected (31.91 KB, text/plain)
2008-07-28 16:46 UTC, rpollack
Contains code that succeeds only because of double quotes (32.24 KB, application/octet-stream)
2008-07-28 16:47 UTC, rpollack

Note You need to log in before you can comment on or make changes to this bug.
Description malkit 2008-05-14 19:42:37 UTC
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.

       <assign name="Assign1">
           <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).

        <repeatUntil name="RepeatUntil1">
            <bpws:throw name="Throw1" faultName="ns1:fault1" faultVariable="Operation12Out1"/>
            <condition>   ( $Operation1In1.timer >= 'P0Y0M0DT0H0M20S' )   </condition>
Comment 1 Vladimir Yaroslavskiy 2008-05-15 08:49:16 UTC
project is RepeatUntilwithTime
Comment 2 Vladimir Yaroslavskiy 2008-05-19 14:24:45 UTC
fixed 1.: 4a86b807736b
Comment 3 Vladimir Yaroslavskiy 2008-05-19 14:27:25 UTC
Created attachment 61564 [details]
Test project
Comment 4 Vladimir Yaroslavskiy 2008-05-19 14:55:35 UTC
fixed 2.: eaff54005b9d
Comment 5 Vladimir Yaroslavskiy 2008-05-19 15:18:51 UTC
I suggested warning instead of error (there a lot of projects with this functionality).
Comment 6 malkit 2008-05-19 19:53:36 UTC
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.

Please clarify.
Comment 7 Vladimir Yaroslavskiy 2008-05-20 09:11:19 UTC
1: warning
2: error
Comment 8 Andrei Chistiakov 2008-05-22 14:49:19 UTC
Verified with NetBeans IDE Dev (Build 200805211202).
Comment 9 pslechta 2008-05-28 08:36:36 UTC
The fix has been ported into the release61_fixes repository.
Comment 10 rpollack 2008-07-25 22:55:49 UTC
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.
Comment 11 Vladimir Yaroslavskiy 2008-07-28 11:10:55 UTC
Please provide the test project.
Comment 12 rpollack 2008-07-28 16:46:59 UTC
Created attachment 65819 [details]
Contains code that is incorrectly rejected
Comment 13 rpollack 2008-07-28 16:47:57 UTC
Created attachment 65820 [details]
Contains code that succeeds only because of double quotes
Comment 14 rpollack 2008-07-28 17:09:51 UTC
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
   <condition>starts-with($purchaseOrder.purchaseOrder/po:orderDescription, 'OrderVal')</condition>
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
(Build 200806161120)).

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.
Comment 15 Vladimir Yaroslavskiy 2008-07-28 17:25:55 UTC
agree, I will change error to warning
Comment 16 Vladimir Yaroslavskiy 2008-07-29 14:06:40 UTC
soa-dev: b73e6a64ac23
main: b7655c41ea9c

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo