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

Reply via email to