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.

Bug 137885 - Validation works incorrectly for Ifs and ForEachs
Summary: Validation works incorrectly for Ifs and ForEachs
Status: RESOLVED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Validation (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vladimir Yaroslavskiy
URL:
Keywords: RELNOTE
Depends on:
Blocks:
 
Reported: 2008-06-21 15:27 UTC by Kirill Sorokin
Modified: 2008-07-28 12:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Sample project (10.81 KB, application/x-compressed)
2008-06-21 15:30 UTC, Kirill Sorokin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Sorokin 2008-06-21 15:27:20 UTC
See the attached project. Note that both If and ForEach contain an Empty (Scope in case of ForEach) activity which has
an error badge. This leads to the idea that something is wrong with these activities. But in fact the cause of the
validation failure lies in the lack of configuration for the enclosing If and ForEach. If needs a <condition>, ForEach
-- a bunch of its specific configuration tags.

The validation bases solely on schema validation, loosing the semantics of BPEL. This might seriously mislead the user,
as the common sense suggests that the error badge is attached to the broken element, not to a child of it. Especially
when the error message talks about invalid content. These element do not yet have any content!

Marking as a P2, as this is a conceptual misbehavior.
Comment 1 Kirill Sorokin 2008-06-21 15:30:53 UTC
Created attachment 63200 [details]
Sample project
Comment 2 Vladimir Yaroslavskiy 2008-06-23 10:14:07 UTC
BPEL schema based validator (#1) extends org.netbeans.modules.xml.xam.spi.XsdBasedValidator (#2) which uses validator
from jdk: javax.xml.validation.Validator (#3). Validator #3 returns errors to the validator #2 where xml source doesn't
match given schema. It is just line and column number of wrong component. After that validator #2 converts line,column
to the model component and passes to validator #1 which informs diagram, editor, navigator. I check that validator #3
really points to the wrong component (<empty> instead of <if>). The problem is in jdk schema validator, so I'm closing
the issue as can not fix.
Comment 3 Sergey Lunegov 2008-06-23 11:23:04 UTC
Vladimir, I think at least we need to open an issue against jdk schema validator. And make the dependency on that issue.
It would be great to check whether simple workaround exists.
Comment 4 Vladimir Yaroslavskiy 2008-06-23 14:00:54 UTC
Bug has been filed: http://swsblweb1.central.sun.com:8080/CrPrint?id=6717819
As to workaround, I don't see it...
Comment 5 Vladimir Yaroslavskiy 2008-06-23 14:01:47 UTC
.
Comment 6 Sergey Lunegov 2008-06-25 08:50:14 UTC
We need to keep it open.
Comment 7 Kirill Sorokin 2008-06-25 14:28:12 UTC
I guess I need to reiterate my point in case I did not make it clear enough initially. As far as I can see, there is NO
issue with schema-based validation: it correctly reports that <empty> is in the wrong place. Once more, from the XML
schema standpoint the erroneous element is <empty> as it is encountered instead of the expected <condition>. <if> is
considered to be correct as it is not responsible for its children.

The problem as I see it is that we (knowingly?) allow too much to the schema-based validation and do not pay attention
to the fact that it will not report error according to BPEL semantics. That is the root cause that we need to fix. The
correct modus operandi should be:
- run schema validation
- for each error reported by it:
  - examine what really happens and correct the error as appropriate (either by moving the error to another element, or
changing the error message to make it more user-friendly, see issue 135148)
Comment 8 Vladimir Yaroslavskiy 2008-06-25 14:41:50 UTC
"...for each error reported by it: - examine what really happens and correct the error..."

your input data is column, raw (or bpel entity) and string message, please, suggest
the reasonable algorithm to correct the error.

IMHO, to correct the error, we should parse bpel document against scheme self.
Comment 9 Sergey Lunegov 2008-06-25 14:44:20 UTC
Kirill, does it mean to implement our own parsing of schema, wsdl etc ? I don't see easy way to do it.
Comment 10 Kirill Sorokin 2008-06-25 18:35:13 UTC
Well.. First I need to admit that I never mentioned "easy". "No such thing as easy in my experience." (c) Lock, Stock
and Two Smoking Barrels.

In this case it's a form of pattern matching. Schema validation simply returns the error message it received from the
underlying jdk validator. Now if the error was received for the first child of <if> and it has the specific errorcode,
which means invalid content, and <if> does not have a condition, then... Easy? No. Doable? Definitely so.

In no way I suggest to be able to correct everything reported by the schema validation. That is the ultimate unreachable
goal. But having a decent coverage of most common mistakes is something we should (must?) do.
Comment 11 Vladimir Yaroslavskiy 2008-06-26 15:45:44 UTC
The bug is not bpel specific. I tried with a wsdl file: the result is the same. In some cases validator points to wring
element. If we fix special case in bpel, it doesn't solve the whole problem.

I think that this issue should be reassigned to the xml to be common and resolved for all xml documents (schema, wsdl,
bpel, xslt).

Any ideas?
Comment 12 Alexey Yarmolenko 2008-06-30 16:00:50 UTC
In general, i like Kirill's idea with wrapping error results, returned by jdk's schema validator with something more 
meaningful for the user. In terms of our validation framework, the code which processes output from schema validator
should recognize this type of error and provide it's own error description.

Comment 13 Vladimir Yaroslavskiy 2008-07-28 12:45:51 UTC
fixed:

soa-dev: e090d21753c7
main: a06863a63fee