You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brett Wooldridge <bw...@alterpoint.com> on 2007/07/31 06:00:58 UTC
java2wsdl -> wsdl2java lossy?
Hi,
I¹ve got a service that I¹m trying to implement and am having an issue.
Actually, I¹m converting from Axis (1.x), and I¹m using code first
development. In Axis I had a service interface defined from which I would
generate WSDL, and then from the WSDL generate client stubs. Luckily, this
seemed to work with (in my case) complete fidelity in that the objects and
interfaces generated for the client-side exactly matched the originating
server-side Java. In CXF I seem to be having a problem where the client
stubs have slightly different return types, and methods that take a complex
object AND a simple type are being collapsed into a single holder-type
object.
(apologies in advance if the formatting comes out crazy, I'll try again if
it does).
Here¹s a compressed version of what I¹ve got for the interface:
@WebService(name = "Scheduler",
targetNamespace = "scheduler.provider.ziptie.org")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface IScheduler {
@WebMethod void addJob(JobData jobData, boolean replace);
}
Here¹s some snippets from the WSDL generated from the interface:
<xs:element name="addJob" type="tns:addJob"/>
<xs:complexType name="addJob">
<xs:sequence>
<xs:element minOccurs="0" ref="tns:jobData"/>
<xs:element name="arg1" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
<wsdl:message name="addJob">
<wsdl:part name="parameters" element="ns1:addJob"></wsdl:part>
</wsdl:message>
<wsdl:portType name="Scheduler">
<wsdl:operation name="addJob">
<wsdl:input name="addJob" message="ns1:addJob"/>
<wsdl:output name="addJobResponse" message="ns1:addJobResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ISchedulerServiceSoapBinding" type="ns1:Scheduler">
<wsdl:operation name="addJob">
<soap:operation soapAction="" style="document"/>
<wsdl:input name="addJob">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="addJobResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
When I generate the client stubs using wsdl2java, I get the following:
@WebService(targetNamespace = "scheduler.provider.ziptie.org",
name = "Scheduler")
public interface Scheduler {
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE
@WebResult(targetNamespace = "scheduler.provider.ziptie.org",
partName = "parameters", name = "addJobResponse")
@WebMethod
public org.ziptie.client.scheduler.AddJobResponse addJob(
@WebParam(targetNamespace = "scheduler.provider.ziptie.org",
partName = "parameters", name = "addJob")
org.ziptie.client.scheduler.AddJob parameters );
}
Notice that¹s it¹s altered my parameterStyle to BARE instead of WRAPPED, and
the method only takes one parameter. I am also not getting a SOAPService
class generated.
My invocation to generate WSDL looks like this:
java2wsdl -verbose
-o scheduler.wsdl
-cp scheduler/bin
-t scheduler.provider.ziptie.org
-d scheduler/META-INF
org.ziptie.provider.scheduler.IScheduler
But curiously, even though I¹m only generating WSDL I get warnings like
these:
INFO: Creating Service {scheduler.provider.ziptie.org}ISchedulerService from
class org.ziptie.provider.scheduler.IScheduler
Jul 30, 2007 10:10:10 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
isWrapperBeanClassNotExist
INFO: Tring to load wrapper class
org.ziptie.provider.scheduler.jaxws.GetFilter
Jul 30, 2007 10:10:10 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
getWrapperClass
WARNING: Can not load wrapper class
org.ziptie.provider.scheduler.jaxws.GetFilter, please check the
@RequestWrapper or @ResponseWrapper and also check the class is in your
classpath
I don¹t really want wrappers generated during this phase (they¹re generated
again when I run wsdl2java), but I don¹t see any way to suppress this
generation.
Thanks for any help you can provide. I am running 2.0.
-Brett
Re: java2wsdl -> wsdl2java lossy?
Posted by James Mao <ja...@iona.com>.
> Hi,
> I¹ve got a service that I¹m trying to implement and am having an issue.
> Actually, I¹m converting from Axis (1.x), and I¹m using code first
> development. In Axis I had a service interface defined from which I would
> generate WSDL, and then from the WSDL generate client stubs. Luckily, this
> seemed to work with (in my case) complete fidelity in that the objects and
> interfaces generated for the client-side exactly matched the originating
> server-side Java. In CXF I seem to be having a problem where the client
> stubs have slightly different return types, and methods that take a complex
> object AND a simple type are being collapsed into a single holder-type
> object.
>
> (apologies in advance if the formatting comes out crazy, I'll try again if
> it does).
>
> Here¹s a compressed version of what I¹ve got for the interface:
>
> @WebService(name = "Scheduler",
> targetNamespace = "scheduler.provider.ziptie.org")
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
> public interface IScheduler {
> @WebMethod void addJob(JobData jobData, boolean replace);
> }
>
> Here¹s some snippets from the WSDL generated from the interface:
>
> <xs:element name="addJob" type="tns:addJob"/>
> <xs:complexType name="addJob">
> <xs:sequence>
> <xs:element minOccurs="0" ref="tns:jobData"/>
> <xs:element name="arg1" type="xs:boolean"/>
> </xs:sequence>
> </xs:complexType>
>
> <wsdl:message name="addJob">
> <wsdl:part name="parameters" element="ns1:addJob"></wsdl:part>
> </wsdl:message>
> <wsdl:portType name="Scheduler">
> <wsdl:operation name="addJob">
> <wsdl:input name="addJob" message="ns1:addJob"/>
> <wsdl:output name="addJobResponse" message="ns1:addJobResponse"/>
> </wsdl:operation>
> </wsdl:portType>
>
> <wsdl:binding name="ISchedulerServiceSoapBinding" type="ns1:Scheduler">
> <wsdl:operation name="addJob">
> <soap:operation soapAction="" style="document"/>
> <wsdl:input name="addJob">
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output name="addJobResponse">
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
>
> When I generate the client stubs using wsdl2java, I get the following:
>
> @WebService(targetNamespace = "scheduler.provider.ziptie.org",
> name = "Scheduler")
> public interface Scheduler {
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE
> @WebResult(targetNamespace = "scheduler.provider.ziptie.org",
> partName = "parameters", name = "addJobResponse")
> @WebMethod
> public org.ziptie.client.scheduler.AddJobResponse addJob(
> @WebParam(targetNamespace = "scheduler.provider.ziptie.org",
> partName = "parameters", name = "addJob")
> org.ziptie.client.scheduler.AddJob parameters );
> }
>
> Notice that¹s it¹s altered my parameterStyle to BARE instead of WRAPPED, and
> the method only takes one parameter. I am also not getting a SOAPService
> class generated.
>
The reason it generate the BARE, is because the WSDL is in BARE style,
the reason WSDL is in BARE is because the java2wsdl can not load the
wrapper bean classes,
You can append the wrapper bean annotation in your SEI, so the tools
knows where to load the wrapper beans, or the tools will go to the
default location, i guess the default values is the jaxws sub-package of
the SEI package.
> My invocation to generate WSDL looks like this:
>
> java2wsdl -verbose
> -o scheduler.wsdl
> -cp scheduler/bin
> -t scheduler.provider.ziptie.org
> -d scheduler/META-INF
> org.ziptie.provider.scheduler.IScheduler
>
> But curiously, even though I¹m only generating WSDL I get warnings like
> these:
>
> INFO: Creating Service {scheduler.provider.ziptie.org}ISchedulerService from
> class org.ziptie.provider.scheduler.IScheduler
> Jul 30, 2007 10:10:10 PM
> org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
> isWrapperBeanClassNotExist
> INFO: Tring to load wrapper class
> org.ziptie.provider.scheduler.jaxws.GetFilter
>
This stacktrace confirmed what i said above.
> Jul 30, 2007 10:10:10 PM
> org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
> getWrapperClass
> WARNING: Can not load wrapper class
> org.ziptie.provider.scheduler.jaxws.GetFilter, please check the
> @RequestWrapper or @ResponseWrapper and also check the class is in your
> classpath
>
> I don¹t really want wrappers generated during this phase (they¹re generated
> again when I run wsdl2java), but I don¹t see any way to suppress this
> generation.
>
You are right, they are annoying, we are working on a new tool , dont'
know the name , maybe 'java2ws',
With java2ws you don't need to java2wsdl <--> wsdl2java, this is the one
of the main goals.
Cheers,
James.
> Thanks for any help you can provide. I am running 2.0.
>
> -Brett
>
>