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.
See attached project bpelTaakServiceSP..... there is a validation error with the setting of the correlation key in the response to a WS call - I have checked this all I can and cannot see what it is complaining about. I do remember a similar issue a month or so ago with the setting of a CK by the response from an activity.
Created attachment 34745 [details] BPEL project
Observations: The error message is: XML validation started. C:/work/beta bugs/86247/bpelTaakServiceSP/bpelTaakServiceSP/src/BPs/spTaakService.bpel:61,24 The property "{http://j2ee.netbeans.org/wsdl/spTaakService}AansluitingTaakID" defined in correlation set "csTaakService" does not have a propertyAlias defined in any of the WSDL definitions directly imported by this BPEL process. You must add a propertyAlias (in one of the imported WSDL definitions) for the WSDL message-type/BPEL variable type used in the enclosing <receive>,<reply>,<invoke>,<onMessage>,<onEvent> activity. The propertyAlias must use one of - messageType-part, type or element attributes similar to how the BPEL variable is defined. The same correlation set is used in two places, and in one place it is considered valid, in the other place it is considered valid. It is considered valid in this usge: <receive name="rcvSetTaakVerwerkt" createInstance="no" partnerLink="plSeeBeyondService" operation="setTaakVerwerkt" portType="ns3:SbynSEI" variable="SetTaakVerwerktIn1"> <correlations> <correlation set="csTaakService" initiate="no"/> </correlations> </receive> It is considered invalid in this usage: <invoke name="invCreateTaak" partnerLink="plTaakService" operation="createTaak" portType="ns2:TaakServiceSEI" inputVariable="CreateTaakIn1" outputVariable="CreateTaakOut1"> <correlations> <correlation set="csTaakService" initiate="yes" pattern="response"/> </correlations> </invoke> So, it is valid in Receive case but invalid in Invoke case. Why? Lets look at the WSDL to see where the receive and reply operations are defined relative to the property : AansluitingTaakID. Property AansluitingTaakID is defined in spTaakService.wsdl. The (receive) operation setTaakVerwerkt is defined in SeeBeyondService.wsdl The (invoke) operation is defined in TaakService.wsdl Ok, no obvious pattern here. Neither the receive, nor the invoke are colocated with the property definition. This looks similar to another bug related to complex WSDL file relationships. I need to see if we can find that bug number. I suspect the problem is in the WSDL object model space, as this is where the other similar problem existed.
Similiar bug : http://www.netbeans.org/issues/show_bug.cgi?id=83617 Marker as invalid. The attached BPEL have TWO WSDL file with the same name TaakService.wsdl. Moreover they are both imported into BPEL and have the same namespace. They also have duplicate portType definition. <!-- porttype --> <portType name="TaakServiceSEI"> <operation name="createTaak"> <input message="tns:TaakServiceSEI_createTaakRequest" /> <output message="tns:TaakServiceSEI_createTaakResponse" /> <fault name="VentourisWSException" message="tns:TaakServiceSEI_VentourisWSException" /> </operation> </portType> So BPEL OM when tryig to resolve operation uses two different operations in various cases. There could be RFE filed against WARNINGS when duplicate definitions exist in wsdl files like current situation.
I'm not sure how the second import got there, but I don't need it so I deleted it. It now validates. I agree that some kind of warning would be useful.
According to the reporter comments the problem was in incorrect WSDL Closing the bug as verified