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 79764 - Compiler requires to set 'parallel' attribute for forEach but validator fails
Summary: Compiler requires to set 'parallel' attribute for forEach but validator fails
Status: VERIFIED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Denis Anisimov
URL:
Keywords:
Depends on:
Blocks: 81459
  Show dependency tree
 
Reported: 2006-07-05 13:02 UTC by Andrey Yamkovoy
Modified: 2006-08-03 13:06 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Yamkovoy 2006-07-05 13:02:23 UTC
If not set attribute 'parallel' in forEach activity then compiler fails with 
message:

Error: cvc-complex-type.4: Attribute 'parallel' must appear on 
element 'forEach'.

If set this attribute then validator fails with message:

Attribute "parallel" is not supported in this release of the BPEL SE.You cannot 
deploy process containing this attribute.
Comment 1 Michael Frisino 2006-07-17 00:10:08 UTC
Hmm, What is situation here?

                   <attribute name="parallel" type="bpws:tBoolean"
                            use="required"/>

Attrbute is required by schema but not supported by runtime. 

Denis do we have other case like this? We should solve in consistent way.

Also this attribute should not be shown in property sheet at all, since it is
out of scope for 5.5. Nikita please remove.
Comment 2 Denis Anisimov 2006-07-18 13:34:45 UTC
I don't understand actually what I need to do.

There is misunderstanding between us and Alaska runtime.
I have schema file from them where this is attribute is commented out.
So this means that they don't support this attribute. This is implemented 
in validation rule. But another validation ( I mean here build-time validation )
said that this attribute should be set. That's correct from schema point of view,
because it is required. So possibly Alaska mean that this attribute should be
always set to some value. WHAT value ? 
I don't know. Schema that they point to me dosn't contain any mentions about it.

>Denis do we have other case like this? We should solve in consistent way.
If you mean - are there more attributes that are required but they are not
supported by runtime then answer - no.
But I believe this is question not for me. This is not first problem that 
we found with misunderstanding between validation (design guidance) and 
runtime validation. I think this is consequence of bad "documentation" that 
we have from Alaska team . This documentation is just schema file and it is 
not sufficient. As consequence we have problem with understanding:
1) what we need to do with not supported attribute ? ( if it have default value 
then should we allow it ?) - we still don't have answer to this question.
2) what we need to do with attribute that required , but not suported and
there is no default vakue ( this is matter of current issue ).
3) some elements are not marked in schema as not supported ( f.e. compensateScope ).

I just want to sya that we need from Alaska much more information then we have now.
Comment 3 Michael Frisino 2006-07-24 10:53:32 UTC
My proposal is as follows:

It seems to me that one solution is that IDE should require presence of
attribute but only allow the value of attribute to = false.
This would require slight change in validation rule for "runtime not supported"
validation.

To implement such logic requires:
IDE should adjust new For Each elements to explicitly set the paraellel
attribute = "false".

Validation system should change runtime validation rule to:
if attribute "parallel" value = true
   return "Error : Parallel processing of For Each element is not supported by
runtime. Please change this value to "false".

This would allow both validators to succeed.
Are there any other suggestions that could solve this issue? 
Comment 4 Michael Frisino 2006-07-26 21:11:53 UTC
Denis, can you execute on my suggestion? The runtime team agrees that it will
not be a problem for the attribute to be present provided its value is "false".
Comment 5 Denis Anisimov 2006-07-27 06:20:56 UTC
Fixed.
Consider attribute value "no" as allowed by runtime.
Validation ( I mean here runtime validation) 
will fail only when attribute is set to "yes".
Comment 6 Andrey Yamkovoy 2006-08-03 13:06:56 UTC
verified:
- attribute removed from properties
- default value is 'no'
- validator post warning if value is 'yes'