This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Two issues with Validation - It fails to catch incorrect assignments and also time duration comparison | ||
|---|---|---|---|
| Product: | soa | Reporter: | malkit <malkit> |
| Component: | BPEL Validation | Assignee: | Vladimir Yaroslavskiy <yaroslavskiy> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | sustaining |
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
Test project
Contains code that is incorrectly rejected Contains code that succeeds only because of double quotes |
||
|
Description
malkit
2008-05-14 19:42:37 UTC
project is RepeatUntilwithTime fixed 1.: 4a86b807736b Created attachment 61564 [details]
Test project
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. Please clarify. 1: warning 2: error Verified with NetBeans IDE Dev (Build 200805211202). The fix has been ported into the release61_fixes repository. http://hg.netbeans.org/release61_fixes/rev/1ee6bef5d13c http://hg.netbeans.org/release61_fixes/rev/97bb908852c0 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 <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. agree, I will change error to warning done: soa-dev: b73e6a64ac23 main: b7655c41ea9c |