You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mark Streit <mc...@gmail.com> on 2012/01/07 21:16:01 UTC
Generated Service proxy (client side) - CXF Tools
Hello *
*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 class.getResource() method as
shown, and works perfectly.
Similar code *generated* with the CXF tools produces this similar 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;
}
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...
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
Any insight would be appreciated.
Thanks
Re: Generated Service proxy (client side) - CXF Tools
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Generated Service proxy (client side) - CXF Tools
Posted by mcs130 <mc...@gmail.com>.
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(/<localized_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-Tools-tp5128342p5146480.html
Sent from the cxf-user mailing list archive at Nabble.com.