I went ahead and logged:

https://issues.apache.org/jira/browse/CXF-4039

and am testing a quick and easy fix for it now.   

HOWEVER: if you use 

-wsdlLocation "classpath:/META-INF/wsdl/BookOrderManagerService.wsdl"

then I think the code it generates is actually correct for you as it would use 
a getResource call instead of a new URL form.   Not 100% sure though.   
However, as I mention in the JIRA , no point in using the "new URL" form if we 
already know the location is an invalid URL.

Thanks!

Dan


On Sunday, January 15, 2012 6:47:16 AM mcs130 wrote:
> Hello
> 
> *(added clarifications)*
> 
> I have a question re: the form of the generated Service subclass code that
> is created when running the wsdl2java tool in CXF
> (org.apache.cxf.tools.wsdlto.WSDLToJava) - I am using CXF 2.5.1
> 
> When using JAX-WS RI's/Metro's *wsimport *tool (from the 2.1 release),
> there is a *generated *static block of code of the form:
> 
>     static {
>         BOOKORDERMANAGERSERVICE_WSDL_LOCATION =
> com.acme.book.webservices.BookOrderManagerService_Service.class.getResource(
> "/META-INF/wsdl/BookOrderManagerService.wsdl"); WebServiceException e =
> null;
>         if (BOOKORDERMANAGERSERVICE_WSDL_LOCATION == null) {
>             e = new WebServiceException("Cannot find
> '/META-INF/wsdl/BookOrderManagerService.wsdl' wsdl. Place the resource
> correctly in the classpath.");
>         }
>         BOOKORDERMANAGERSERVICE_EXCEPTION = e;
>     }
> 
> 
> This uses the WSDL file packaged in the JAR file and pulled from the
> /META-INF/wsdl location of that JAR using the
> *</generated_fully_qualified_service_classname/>.class.getResource(/<localiz
> ed_path_to_wsdl_in_jar>/)* method as
> shown, and works perfectly.
> 
> Similar code *generated *with the CXF tools produces this block in
> the following form:
> 
> 
>     static {
>         URL url = null;
>         try {
>             url = new URL("/META-INF/wsdl/BookOrderManagerService.wsdl");
>         } catch (MalformedURLException e) {
> java.util.logging.Logger.getLogger(BookOrderManagerService.class.getName())
>                 .log(java.util.logging.Level.INFO,
>                      "Can not initialize the default wsdl from {0}",
> "META-INF/wsdl/BookOrderManagerService.wsdl");
>         }
>         WSDL_LOCATION = url;
>     }
> 
> In this case, the WSDL_LOCATION is defined using the URL class and the same
> value of the String representing the localized path of the WSDL file,
> relative to the JAR file content.
> 
> The client code works in EITHER case but the CXF-generated code produces
> the message:
> 
> Jan 7, 2012 8:59:11 AM com.acme.book.webservices.BookOrderManagerService
> <clinit>
> INFO: Can not initialize the default wsdl from
> /META-INF/wsdl/BookOrderManagerService.wsdl
> Jan 7, 2012 8:59:21 AM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromWSDL
> 
> 
> Obviously it is 2 different approaches with the first one working since the
> class.getResource() is always available in the classpath.  The CXF code
> accomplishes a similar thing but produces the exception message shown, yet
> continues successfully to create the instance...which seemed puzzling.
> (perhaps I am misunderstanding?).
> 
> We are looking to potentially move to the CXF stack (for both JAX-WS and
> JAX-RS) in a large scale environment and I want to make sure I understand
> what I am seeing.
> 
> 
> Jan 7, 2012 3:06:52 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromWSDL
> INFO: Creating Service {
> http://webservices.book.acme.com/}BookOrderManagerService from WSDL:
> jar:file:/C:/Users/xxxxxxxxx/workspace/EclipseIndigo/CXFTestWSClient/deploy/
> CXFTestWSClient.jar!/META-INF/wsdl/BookOrderManagerService.wsdl
> 
> /I do recall some time ago that the wsimport tool in JAX-WS RI 2.0 (and
> JDK6) created similar code which was eventually changed in one of the JAX-WS
> RI 2.1.x releases to using this "getResource()" method approach.  Before
> that, there was a bug where the String path provided to the URL constructor
> was the absolute file system path to the file...which was clearly a
> problem./
> 
> 
> Any insight would be appreciated.
> 
> Thank you.
> 
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Generated-Service-proxy-client-side-CXF-Too
> ls-tp5128342p5146480.html Sent from the cxf-user mailing list archive at
> Nabble.com.
-- 
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply via email to