cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Algirdas Veitas <apvei...@gmail.com>
Subject Re: java2ws ignoring targetNamespace?
Date Thu, 21 Jul 2011 20:41:03 GMT
Hi Daniel,

In doing a bit more experimentation, it looks like the "issue" manifests
itself even if you are not extending an interface.  The following service
interface, results in the same issue:

package com;
@WebService
public interface UberService
{
       @WebMethod
       @RequestWrapper(targetNamespace="http://com.bar")
       @ResponseWrapper(targetNamespace="http://com.bar")
       String myBarMethod(String x);
}

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="
http://com/" elementFormDefault="unqualified" targetNamespace="http://com/"
version="1.0">
<xs:element name="myBarMethod" type="tns:myBarMethod"/>
<xs:element name="myBarMethodResponse" type="tns:myBarMethodResponse"/>
<xs:complexType name="myBarMethod">
    <xs:sequence>
      <xs:element minOccurs="0" name="arg0" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
<xs:complexType name="myBarMethodResponse">
    <xs:sequence>
      <xs:element minOccurs="0" name="return" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Thanks,
Al

On Thu, Jul 21, 2011 at 3:59 PM, Algirdas Veitas <apveitas@gmail.com> wrote:

> Hi Daniel,
>
> Thanks for the response.  I added the @RequestWrapper/@ResponseWrapper as
> recommended, but the outcome is the same: the wrapper's are not being put
> into the proper namespace :(
>
> Here are the updated Java interfaces:
>
>
> @WebService(targetNamespace="http://com.foo")
> public interface FooService {
>
>    @WebMethod
>    @RequestWrapper(targetNamespace="http://com.foo")
>    @ResponseWrapper(targetNamespace="http://com.foo")
>
>    @WebResult(targetNamespace="http://com.foo")
>    String myFooMethod(String x);
>
> }
>
> @WebService(targetNamespace="http://com.bar")
> public interface BarService {
>    @WebMethod
>    @RequestWrapper(targetNamespace="http://com.bar")
>    @ResponseWrapper(targetNamespace="http://com.bar")
>
>    @WebResult(targetNamespace="http://com.bar")
>    String myBarMethod(String x);
> }
>
> Thanks,
> Al
>
>
>
> On Thu, Jul 21, 2011 at 3:39 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
>>
>>
>> You may need to also add @RequestWrapper/@ResponseWrapper annotations to
>> the
>> methods to define the namespaces used for the generated wrappers.   The
>> @WebResult/@WebParam annotations define them for the elements IN the
>> request/response wrapper sequences (for example, you see the line:
>>
>> <xs:element minOccurs="0" ref="ns2:return"/>
>>
>> to refer to the element in a different namespace).    The other
>> annotations
>> would generate the appropriate wrapper elements in their appropriate
>> namespace.
>>
>> Dan
>>
>>
>>
>> On Thursday, July 21, 2011 10:30:03 AM Algirdas Veitas wrote:
>> > Hi,
>> >
>> > Am hoping someone can give me a hand with a potential issue (or a
>> > misunderstanding on my part) with java2ws with respect to the target
>> > namespaces being generated for the operation message types.
>> >
>> > Some background: We have a requirement to move roughly 15 web services
>> from
>> > "Code-First" to "Contract-First".  In addition, we now need to collapse
>> > these 15 web services into 1 big WSDL (not my choice).  To date we have
>> been
>> > using java2ws via the cxf-java2ws-plugin (2.3.1) to generate the WSDL
>> for
>> > each of our services.
>> >
>> > Now, to boil this (potential) issue (or misunderstanding) down to a
>> small
>> > size, let say we have 2 existing Web Services and that we need collapse
>> into
>> > 1 WSDL and then move away from Code-First.  Here are there definitions:
>> >
>> > package com.foo;
>> > @WebService(targetNamespace="http://com.foo")
>> > public interface FooService {
>> >    @WebMethod
>> >    @WebResult(targetNamespace="http://com.foo")
>> >    String myFooMethod(String x);
>> > }
>> >
>> > package com.bar;
>> > @WebService(targetNamespace="http://com.bar")
>> > public interface BarService {
>> >    @WebMethod
>> >    @WebResult(targetNamespace="http://com.bar")
>> >    String myBarMethod(String x);
>> > }
>> >
>> > After running java2ws on these 2 services, we see that the
>> targetNamespace
>> > for elements and complexTypes  "myBarMethod" and "myBarResponse" are "
>> > http://com.bar", which is expected (some attributes and other elements
>> > removed for clarity):
>> >
>> > <xs:schema xmlns:tns="http://com.bar" targetNamespace="http://com.bar"
>> > version="1.0">
>> > <xs:element name="myBarMethod" type="tns:myBarMethod"/>
>> > <xs:element name="myBarMethodResponse" type="tns:myBarMethodResponse"/>
>> > <xs:complexType name="myBarMethod">
>> >     <xs:sequence>
>> >       <xs:element minOccurs="0" name="arg0" type="xs:string"/>
>> >     </xs:sequence>
>> >   </xs:complexType>
>> > </xs:schema>
>> >
>> >
>> > Now, our solution to merge all of these services into one WSDL was to
>> > initially generate the WSDL using java2ws and then migrate our
>> > infrastructure away from java2ws to start using wsdl2java.  The
>> following
>> > solution seemed to be the most efficient to get us there.  We would
>> > basically create a temporary UberService interface that extended
>> FooService
>> > and BarService like so to generate the 1 big WSDL
>> >
>> > package com;
>> > @WebService
>> > public interface UberService
>> >   extends FooService , BarService {
>> > }
>> >
>> > We then process UberService via java2ws and a UberService.wsdl is
>> generated
>> > and all methods from each service are merged into one WSDL, exactly what
>> we
>> > wanted.  However, we did notice that element/complexType "myBarMethod" ,
>> > "myBarMethodResponse" , "myFooMethod" and "myFooMethodResponse" are now
>> in
>> > the "http://com" namespace instead of the expected http://com.bar and
>> > http://com.foo namespaces respectively
>> >
>> > The 3 WSDL's are attached....
>> >
>> > It seems like java2ws in this situation (processing an interface that
>> > extends other interfaces annotated with @WebService) is ignoring the
>> > targetNamespace that is defined for both FooService and BarService.
>>  There
>> > may be a good reason for doing this (specifications, etc) but am not
>> sure if
>> > it is a bug or a feature or PEBKAC :)
>> >
>> > Anyone have any thoughts?
>> >
>> > Al
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message