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.
GFESBv2 (stable) running no OpenSolaris2008.11 (in vbox). - create a BPEL SU using an abstract WSDL - in CASA, add a SOAP BC SU and connect to the BPEL SU - deploy - When I look at the WSDL generated by CASA, the abstract wsdl for the BP is referred to in an import statement so the CASA-generated WSDL doesn´t include any Abstract WSDL info. - create a new client BP and try to generate a partner link for the previously deployed service -- if you drag the casa-generated wsdl from the project explorer to the bpel canvas, the bpel editor cannot create a partner link because there is no abstract wsdl info in the WSDL file - it will not follow the import statement to the abstract wsdl. -- if you import the deployed wsdl E.g., URL_TO_MY_SERVICE?WSDL, both the abstract and concrete parts are imported to the bpel project (in separate files). However it is still not possible to create a partner link because the PL wizard will not follow the import statement that connects the two.
I believe the spec forbids this. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738483 "However, documents (or namespaces) imported by an imported document (or namespace) MUST NOT be transitively imported by the WS-BPEL processor. In particular, this means that if an external item is used by a WS-BPEL process, then a document (or namespace) that defines that item MUST be directly imported by the process; observe however that this requirement does not limit the ability of the imported document itself to import other documents or namespaces."
The problem Jason encountered is a bpel tooling issue. The tooling can easily figure out the import closure and generate all necessary wsdl and xsd imports needed to insert into bpel. Otherwise, we need to explicitly stated that the user can only DnD wsdls with no import into bpel tooling.
This way.. Yes. :)