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.
open-jbi-components/driver-tests/bpelse/POJOCalls/memberJavaMethod/memberJavaMethod/src/Synchronous.bpel fails validation with the following error. What this means? I do not see any problem with the COPY and it works fine in the run time. C:/GlassFishESB/trunk/open-jbi-components/driver-tests/bpelse/POJOCalls/memberJavaMethod/memberJavaMethod/src/Synchronous.bpel:105,12 ERROR: It does not make much sense to have duplicate copies - the order in which <copy>s are executed is not defined. C:/GlassFishESB/trunk/open-jbi-components/driver-tests/bpelse/POJOCalls/memberJavaMethod/memberJavaMethod/src/Synchronous.bpel:101,12 ERROR: It does not make much sense to have duplicate copies - the order in which <copy>s are executed is not defined.
related issue http://www.netbeans.org/issues/show_bug.cgi?id=135160
The fragment of code is: <assign> <copy ...> <from>...</from> <to>$outputVar.resultType/ns2:paramA</to> </copy> <copy ...> <from>...</from> <to>$outputVar.resultType/ns2:paramA</to> </copy> </assign> The different values are copied to the same variable.part/step. This code does not make much sense -- the order in which <copy>s are executed is not defined. So, the final result of assign is not defined too. To catch this situation, validation rule was added.
Based on the discussion below > 1st copy's "to" is used as input of 2nd copy's "from". Are you saying > this is invalid? "Static Analysis" does not say it. My bad -- did not read the statements thoroughly enough, concentrated on the identical <to> statements... If we can guarantee the <copy> execution order, then this makes perfect sense (up to the obvious difficulties visualizing the <copy>'ies). > Yes! this is error today. I am fine if we agree to change it to warning, > same time message is misleading. It is not duplicate "copy". Warning > needs to say something in the line of > Assign activity compromises on business process portability, its > behavior depends on execution order of "copy" elements. OK. So what if we update the validation rule to be as below? 1) If both <from>'s and <to>'s are the same -- issue an error, as these are duplicate copies. 2) If only <to>'s are the same, we issue a warning with the message you suggested. I really like it. Kirill
fixed: http://hg.netbeans.org/soa-dev65?cmd=changeset;node=e7977d77cc35
Tested with attached project in 6-dec-09 build of GFESBV2.2. Fix is working fine.
Created attachment 92255 [details] project Project.
Closing the ticket.