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.
Summary: | Failed to call a bpel web service in a java application | ||
---|---|---|---|
Product: | webservices | Reporter: | _ hong_lin <hong_lin> |
Component: | Code | Assignee: | Roderico Cruz <rcruz> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | slunegov |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
TRS sample project
screenshot about the error dialog found some exceptions in server.log file. |
Description
_ hong_lin
2007-11-08 01:26:39 UTC
Created attachment 52692 [details]
TRS sample project
Created attachment 52693 [details]
screenshot about the error dialog
Created attachment 52694 [details]
found some exceptions in server.log file.
When the client was created, the URL of the deployed wsdl of the BPEL process in the Composite App was passed to the wizard. This wsdl uses the url of the deployed composite app (in the 18181 port). This wsdl in turn imports other wsdls corresponding to the actual services that are being orchestrated in the BPEL process. These actual services are deployed in the 8080 port. These wsdls import the XSD schema, using a relative path, specifying it to be in the same directory as the wsdl. When these wsdls are processed by the JAXWS-RI runtime, the runtime thinks the XSD file is deployed in the 8080 port, relative to the deploy URL of the wsdl. Actually it is not deployed there. What happens is that the service wsdls are deployed relative to the composite app deploy URL. Thus, the URL of the deployed BPEL process in the composite app cannot be used when creating a JAXWS client. Instead, the location of the BPEL wsdl in the BPEL project (its local path) should be used instead, as this has the correct import location relationships. I am downgrading this since there is a workaround. I am not even sure if this is a bug, so meanwhile I will downgrade to a P3. btw, if you get past this, the JAXWS-RI runtime will complain of a duplicate element spec in the schema file. The runtime is simply following the binding rules of JAXB. This is a use case where JAXB customization is needed in order to generate the correct Java classes. rico, what is the workaround? Would you please provide the steps? Thanks. Hong, As discussed with you the change in the step of creating the web service client is to specify the local file of the wsdl in the BPEL project instead of the URL. With this, the import dependencies are taken care of correctly by the XML retriever. The root of the problem is really that we do not currently support creating web service clients directly from a BPEL project. With this support, all idiosyncrancies of BPEL deployment will be considered in the web service client generation. There is an outstanding RFE for this: http://www.netbeans.org/issues/show_bug.cgi?id=117864. As such I am closing this as a duplicate of this RFE. Also, wsimport will fail on the OTA XSD file because of an element name that is the same as an attribute name (which of course breaks the Java generation). The JAXB solution to this is to use a JAXB customization file that will direct the JAXB generator to generate a field name with a different name. This can be fed to the project via the Edit Web service attributes dialog. Let me know if you need this customization file (aka JAXB Binding file)for your customer. *** This issue has been marked as a duplicate of 117864 *** Anyway, the workaround is, Steps 1~6 keep the same. 7. In the "New Web Service Client" wizard, check "Local File" under "Specify the WSDL file of the Web Service". 8. Browse to the BPEL wsdl file location, in my case. 9. Enter a package name if you want. Then click Finish. hello guys someone can give me a example of how to call a bpel process in a java application please help me i need it thanks |