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 <[email protected]> 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 <[email protected]> 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
> >> [email protected]
> >> http://dankulp.com/blog
> >> Talend - http://www.talend.com
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
