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 158694 - BPEL should automatically generate transitive imports when adding WSDL/XSD files
Summary: BPEL should automatically generate transitive imports when adding WSDL/XSD files
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Project (show other bugs)
Version: 6.x
Hardware: PC Solaris
: P3 blocker (vote)
Assignee: Sergey Lunegov
Depends on:
Reported: 2009-02-17 18:17 UTC by jbaragry
Modified: 2009-02-19 11:40 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description jbaragry 2009-02-17 18:17:52 UTC
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.
Comment 1 Kirill Sorokin 2009-02-17 18:38:04 UTC
I believe the spec forbids this.

"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."
Comment 2 Tientien Li 2009-02-18 16:06:23 UTC
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.  

Comment 3 Kirill Sorokin 2009-02-19 11:38:57 UTC
This way.. Yes. :)