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: | Generated wsimport keeps reference to wsdl file in wsdllocation option | ||
---|---|---|---|
Product: | webservices | Reporter: | Mei Wu <mwu> |
Component: | JAX-WS | Assignee: | Roderico Cruz <rcruz> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | mkuchtiak, pjiricka |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Mei Wu
2008-09-03 21:24:42 UTC
More to this issue, although there is an "Edit Web Service Attributes" option on the Web service Reference node in the project, and there is also a tab to customize wsimport, one can not turn off the wsdllocation This is a well known problem and caused mostly by JAX-WS framework and its limitation: For local WSDL file, JAX-WS:wsimport utility generates a javax.xml.ws.Service implementation that has the local file reference in it's static block. This can be only satisfactorily overriden by @javax.xml.ws.WebServiceRef annotation, e.g. @WebServiceRef(wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") private HelloService_Service service; then the instance of Service class can be used in code (e.g.. in the servlet doPost() method, e.g. : ... hello.HelloService port = service.getHelloServicePort(); java.lang.String result = port.hello(); ... The problem is this work only in web servers supporting @WebServiceRef injections (servers supporting JSR109 specification), and in injectable objects, e.g. - servlets - web services - ejb ... (these are object initialized at deployment time) Generally: - @WebServiceRef injection works with GlassFish (target server) but not with Tomcat - @WebServiceRef injection works in servlets/filters but not in JSP (Web application) - @WebServiceRef injection doesn't work in J2SE Project (Java applications) In cases the @WebServiceRef injection is not supported, we generate a client code like the following: hello.HelloService_Service service = new hello.HelloService_Service(); hello.HelloService port = service.getHelloServicePort(); java.lang.String result = port.hello(); which causes problems with local wsdl files and portability. For now, I see the only workaround for these problems: don't use local wsdl files to generate clients, or use @WebServiceRef injection wherever it's possible. The wsimport:wsdlLocation attribute is used to generate @WebServiceRef:wsdlLocation attribute in javax.xml.ws.Service implementation class. The ability to change wsimport:wsdlLocation would enable you to change the location of wsdl file, e.g. from one local location to another location. It's basically the same as what you can do in Refresh action on client node - In the action dialog you can also change the wsdl location: Steps: - copy wsdl file to your friend - ask him to refresh client and point to new wsdl file location Milan, sounds like you are saying that the real fix needs to be done in the JAX-WS stack itself. I think this is quite important, because it will be a common scenario to use WS clients from non-injectable targets, such as utility classes/POJOs. Is there a bug filed on the side of JAX-WS runtime? We should have one. Actually I started to look at this yesterday. I am looking at the possibility of solving this using the catalog facility as specified in the jaxws spec (jax-ws-catalog.xml). Will let you know, meanwhile let us keep the WONTFIX resolution. Thanks Milan. just a note that there's filed issue 123394 already.... |