You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Algirdas Veitas <ap...@gmail.com> on 2011/07/21 16:30:03 UTC
java2ws ignoring targetNamespace?
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
Re: java2ws ignoring targetNamespace?
Posted by arikgold <go...@gmail.com>.
Hi Daniel,
Thanks for the quick response :)
Is this behavior by design?
I expect that when I specify a target namespace for WebService, it will
apply also to the WebMethods. don't you think so? Do I miss something?
What do you mean by "put the service and *binding* in that namespace"?
Thanks again,
Arik
--
View this message in context: http://cxf.547215.n5.nabble.com/java2ws-ignoring-targetNamespace-tp4619618p5524293.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: java2ws ignoring targetNamespace?
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, February 28, 2012 12:19:05 AM arikgold wrote:
> Hi,
>
> I am new in the java2ws business.
> Can you explain the purpose and functionality of the '-t' argument (target
> namespace).
It would really just set the targetNamespace on the root of the wsdl and would
put the service and binding in that namespace (possible the portType as well,
not really sure). However, I don't think it would have any impact on the
generated schema.
Dan
> I want to use it instead of specifying the targetnamespace attribute for
> each WebService and WebMethod annotation (as described in this post).
>
> Is it possible?
> Thanks in advance
> Arik
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/java2ws-ignoring-targetNamespace-tp4619618p
> 5521165.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: java2ws ignoring targetNamespace?
Posted by arikgold <go...@gmail.com>.
Hi,
I am new in the java2ws business.
Can you explain the purpose and functionality of the '-t' argument (target
namespace).
I want to use it instead of specifying the targetnamespace attribute for
each WebService and WebMethod annotation (as described in this post).
Is it possible?
Thanks in advance
Arik
--
View this message in context: http://cxf.547215.n5.nabble.com/java2ws-ignoring-targetNamespace-tp4619618p5521165.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: java2ws ignoring targetNamespace?
Posted by Algirdas Veitas <ap...@gmail.com>.
Adding localName to the RequestWrapper/ResponseWrapper took care of it, for
both cases.
Thanks!
On Thu, Jul 21, 2011 at 4:45 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Can you add localName attributes to those?
>
> @RequestWrapper(localName="myBarMethod",
> targetNamespace="http://com.bar")
>
> @ResponseWrapper(localName="myBarMethodResponse"
> targetNamespace="http://com.bar")
>
> And seeing if that helps. If so, try removing them and then adding the
> name
> attribute to the @WebMethod.
>
> Looking at the code, I think it needs to have one of those defined, but
> I'd
> like to verify that.
>
> Dan
>
>
>
> On Thursday, July 21, 2011 4:41:03 PM Algirdas Veitas wrote:
> > 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 <ap...@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 <dk...@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
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: java2ws ignoring targetNamespace?
Posted by Daniel Kulp <dk...@apache.org>.
Can you add localName attributes to those?
@RequestWrapper(localName="myBarMethod",
targetNamespace="http://com.bar")
@ResponseWrapper(localName="myBarMethodResponse"
targetNamespace="http://com.bar")
And seeing if that helps. If so, try removing them and then adding the name
attribute to the @WebMethod.
Looking at the code, I think it needs to have one of those defined, but I'd
like to verify that.
Dan
On Thursday, July 21, 2011 4:41:03 PM Algirdas Veitas wrote:
> 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 <ap...@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 <dk...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: java2ws ignoring targetNamespace?
Posted by Algirdas Veitas <ap...@gmail.com>.
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 <ap...@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 <dk...@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
>>
>
>
Re: java2ws ignoring targetNamespace?
Posted by Algirdas Veitas <ap...@gmail.com>.
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 <dk...@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
>
Re: java2ws ignoring targetNamespace?
Posted by Daniel Kulp <dk...@apache.org>.
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