You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jason Rosenberg <jr...@shopzilla.com> on 2007/08/08 20:53:50 UTC

Generated WSDL in 2 parts with CXF (was only 1 file in XFire)

Hi,

I just converted a simple app from XFire to CXF....It's a code-first
app....The generated WSDL is now a bit different, in that it is in 2 parts,
the main WSDL uses an import to point to a sub-WSDL....The sub-WSDL contains
these parts:

wsdl:types
wsdl:message
wsdl:portType

And the main wsdl contains these parts:

wsdl:import (importing the sub-wsdl)
wsdl:binding
wsdl:service

Is there any reason for this, is it expected?  I can't decide if I should be
concerned or not with it, one thing I can think of is if I want to cache the
WSDL locally, it is a bit problematic to also cache the sub-WSDL pointed to
via a URL (and not also a local file)....

Thanks for any insight,

Jason


-- 
View this message in context: http://www.nabble.com/Generated-WSDL-in-2-parts-with-CXF-%28was-only-1-file-in-XFire%29-tf4238365.html#a12059667
Sent from the cxf-user mailing list archive at Nabble.com.


Re: Generated WSDL in 2 parts with CXF (was only 1 file in XFire)

Posted by Daniel Kulp <dk...@apache.org>.
Yep.   JAX-WS/JWS spec compliance issue.   

It's actually something to be careful of.   I ran into a similar issue 
yesterday.    In one of my codefirst things, I moved the interface out 
of the package with the server and all kinds of things broke as the 
generated  wsdls and schemas had all new namespaces.   My QNames I had 
setup were all wrong, etc....   targetNamespace can definitely save some 
aggravation.

Dan



On Wednesday 08 August 2007 20:44, Jason Rosenberg wrote:
> I figured it out, it had to do with the 'targetNamespace'....
>
> Apparently CXF requires both the interface and implementing classes to
> be annotated with the same 'targetNamespace' within the @WebService
> annotation....So, once I made sure that was the case, the wsdl is now
> back to a single file....It was being broken up before, one for each
> targetNamespace....
>
> The reason they were different in the first place, was just the
> default handling (the 'targetNamespace' was unspecified in the
> implementation class, and so it was derived from the class name, which
> is in a different sub-package 'impl' from the interface class)....
>
> Apparently XFire only looked at the target namespace specified for the
> interface class....
>
> I had to get it just right too (include the trailing "/"), otherwise
> it didn't match up....
>
> Anyway....mystery solved....
>
> Jason
>
> Glen Mazza-2 wrote:
> > I'm not sure, perhaps it was designed that way so the sub-WSDL could
> > be reusable with other "outer" WSDLs?  Or might only need to be
> > cached once for multiple outer WSDLs, perhaps.
> >
> > Glen
> >
> > Am Mittwoch, den 08.08.2007, 11:53 -0700 schrieb Jason Rosenberg:
> >> Hi,
> >>
> >> I just converted a simple app from XFire to CXF....It's a
> >> code-first app....The generated WSDL is now a bit different, in
> >> that it is in 2 parts,
> >> the main WSDL uses an import to point to a sub-WSDL....The sub-WSDL
> >> contains
> >> these parts:
> >>
> >> wsdl:types
> >> wsdl:message
> >> wsdl:portType
> >>
> >> And the main wsdl contains these parts:
> >>
> >> wsdl:import (importing the sub-wsdl)
> >> wsdl:binding
> >> wsdl:service
> >>
> >> Is there any reason for this, is it expected?  I can't decide if I
> >> should be
> >> concerned or not with it, one thing I can think of is if I want to
> >> cache the
> >> WSDL locally, it is a bit problematic to also cache the sub-WSDL
> >> pointed to
> >> via a URL (and not also a local file)....
> >>
> >> Thanks for any insight,
> >>
> >> Jason

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: Generated WSDL in 2 parts with CXF (was only 1 file in XFire)

Posted by James Mao <ja...@iona.com>.
Hi Jason,

It was fixed in https://issues.apache.org/jira/browse/CXF-669,
if the SEI and Impl have different targetNamespaces, we do generate two 
wsdls

James

> I figured it out, it had to do with the 'targetNamespace'....
>
> Apparently CXF requires both the interface and implementing classes to be
> annotated with the same 'targetNamespace' within the @WebService
> annotation....So, once I made sure that was the case, the wsdl is now back
> to a single file....It was being broken up before, one for each
> targetNamespace....
>
> The reason they were different in the first place, was just the default
> handling (the 'targetNamespace' was unspecified in the implementation class,
> and so it was derived from the class name, which is in a different
> sub-package 'impl' from the interface class)....
>
> Apparently XFire only looked at the target namespace specified for the
> interface class....
>
> I had to get it just right too (include the trailing "/"), otherwise it
> didn't match up....
>
> Anyway....mystery solved....
>
> Jason
>
>
>
> Glen Mazza-2 wrote:
>   
>> I'm not sure, perhaps it was designed that way so the sub-WSDL could be
>> reusable with other "outer" WSDLs?  Or might only need to be cached once
>> for multiple outer WSDLs, perhaps.
>>
>> Glen
>>
>> Am Mittwoch, den 08.08.2007, 11:53 -0700 schrieb Jason Rosenberg:
>>     
>>> Hi,
>>>
>>> I just converted a simple app from XFire to CXF....It's a code-first
>>> app....The generated WSDL is now a bit different, in that it is in 2
>>> parts,
>>> the main WSDL uses an import to point to a sub-WSDL....The sub-WSDL
>>> contains
>>> these parts:
>>>
>>> wsdl:types
>>> wsdl:message
>>> wsdl:portType
>>>
>>> And the main wsdl contains these parts:
>>>
>>> wsdl:import (importing the sub-wsdl)
>>> wsdl:binding
>>> wsdl:service
>>>
>>> Is there any reason for this, is it expected?  I can't decide if I should
>>> be
>>> concerned or not with it, one thing I can think of is if I want to cache
>>> the
>>> WSDL locally, it is a bit problematic to also cache the sub-WSDL pointed
>>> to
>>> via a URL (and not also a local file)....
>>>
>>> Thanks for any insight,
>>>
>>> Jason
>>>
>>>
>>>       
>>
>>     
>
>   

Re: Generated WSDL in 2 parts with CXF (was only 1 file in XFire)

Posted by Jason Rosenberg <jr...@shopzilla.com>.
I figured it out, it had to do with the 'targetNamespace'....

Apparently CXF requires both the interface and implementing classes to be
annotated with the same 'targetNamespace' within the @WebService
annotation....So, once I made sure that was the case, the wsdl is now back
to a single file....It was being broken up before, one for each
targetNamespace....

The reason they were different in the first place, was just the default
handling (the 'targetNamespace' was unspecified in the implementation class,
and so it was derived from the class name, which is in a different
sub-package 'impl' from the interface class)....

Apparently XFire only looked at the target namespace specified for the
interface class....

I had to get it just right too (include the trailing "/"), otherwise it
didn't match up....

Anyway....mystery solved....

Jason



Glen Mazza-2 wrote:
> 
> I'm not sure, perhaps it was designed that way so the sub-WSDL could be
> reusable with other "outer" WSDLs?  Or might only need to be cached once
> for multiple outer WSDLs, perhaps.
> 
> Glen
> 
> Am Mittwoch, den 08.08.2007, 11:53 -0700 schrieb Jason Rosenberg:
>> Hi,
>> 
>> I just converted a simple app from XFire to CXF....It's a code-first
>> app....The generated WSDL is now a bit different, in that it is in 2
>> parts,
>> the main WSDL uses an import to point to a sub-WSDL....The sub-WSDL
>> contains
>> these parts:
>> 
>> wsdl:types
>> wsdl:message
>> wsdl:portType
>> 
>> And the main wsdl contains these parts:
>> 
>> wsdl:import (importing the sub-wsdl)
>> wsdl:binding
>> wsdl:service
>> 
>> Is there any reason for this, is it expected?  I can't decide if I should
>> be
>> concerned or not with it, one thing I can think of is if I want to cache
>> the
>> WSDL locally, it is a bit problematic to also cache the sub-WSDL pointed
>> to
>> via a URL (and not also a local file)....
>> 
>> Thanks for any insight,
>> 
>> Jason
>> 
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Generated-WSDL-in-2-parts-with-CXF-%28was-only-1-file-in-XFire%29-tf4238365.html#a12064516
Sent from the cxf-user mailing list archive at Nabble.com.


Re: Generated WSDL in 2 parts with CXF (was only 1 file in XFire)

Posted by Glen Mazza <gl...@verizon.net>.
I'm not sure, perhaps it was designed that way so the sub-WSDL could be
reusable with other "outer" WSDLs?  Or might only need to be cached once
for multiple outer WSDLs, perhaps.

Glen

Am Mittwoch, den 08.08.2007, 11:53 -0700 schrieb Jason Rosenberg:
> Hi,
> 
> I just converted a simple app from XFire to CXF....It's a code-first
> app....The generated WSDL is now a bit different, in that it is in 2 parts,
> the main WSDL uses an import to point to a sub-WSDL....The sub-WSDL contains
> these parts:
> 
> wsdl:types
> wsdl:message
> wsdl:portType
> 
> And the main wsdl contains these parts:
> 
> wsdl:import (importing the sub-wsdl)
> wsdl:binding
> wsdl:service
> 
> Is there any reason for this, is it expected?  I can't decide if I should be
> concerned or not with it, one thing I can think of is if I want to cache the
> WSDL locally, it is a bit problematic to also cache the sub-WSDL pointed to
> via a URL (and not also a local file)....
> 
> Thanks for any insight,
> 
> Jason
> 
>