Indeed! Thanks.
Daniel Kulp <[EMAIL PROTECTED]> wrote: Double check those annotations. I expect the one on the impl has: "http://videoservice.xx.yy.com"; and the one on the interface has: "http://videoservice.xx.yy.com/"; The trailing slash is significant. Dan On May 22, 2008, at 3:20 PM, Jo wrote: > Dan, > > The annotated targetNameSpace on the interface and the > implementation class were the same: > > The following is part of the generated WSDL. > Apparently, CXF treats the same string differently. As > you can see > the generated wsdl comes with the default namespace, > "ns1", and "tsn" all pointed to the same namespace. > > > > - > targetNamespace="http://videoservice.xx.yy.com"; > xmlns:ns1="http://videoservice.xx.yy.com/"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:tns="http://videoservice.xx.yy.com"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema";> > > location="http://localhost:8080/video/services/testVideoService?wsdl=VideoService.wsdl > > " > namespace="http://videoservice.xx.yy.com/"; /> > - > type="ns1:VideoService"> > > transport="http://schemas.xmlsoap.org/soap/http"; / > > > ------------------------------------------------------------- > From£ºDaniel Kulp > Sent£º2008-05-22 14:52:14 > To£ºusers > cc£º > Subject£ºRe: XFire to CXF issue > > > OOOHHH.... this is a completely different issue. > :-) > > If you look, the wsdl at the first one imports the > wsdl at the second > one and different targetNamespaces are set. This is > caused by the > "targetNamespace" attribute on you @WebService > annotations being > different for the interface and the implementation. > (or it's > missing on one or the other)(or missing on both and > the interface is > in a different package) > > This is completely a spec compliance thing. What CXF > is doing is per > JWS spec. What XFire was doing is not. The fix is > just to make > sure the same targetNamespace is stuck into the > @WebService annotation > for the impl and the interface. > > Dan > > > > On May 22, 2008, at 2:46 PM, Jo wrote: > >> if I use the following URL (deployed both in tomcat >> 5.5 and 6.0), I got the wrong WSDL (WebParam > missing): >> > http://localhost:8080/video/services/testVideoService?wsdl >> >> If I use the following URL, everything is alright. >> >> > http://localhost:8080/video/services/testVideoService?wsdl=videoService.wsdl >> >> Is this a new feature in CXF or not? >> >> > ------------------------------------------------------------- >> From£ºDaniel Kulp >> Sent£º2008-05-22 13:44:10 >> To£ºusers >> cc£º >> Subject£ºRe: XFire to CXF issue >> >> >> >> Any chance you can submit a test case? I just > added >> your method to >> one of our test cases and the wsdl generated >> completely properly: >> >> >> type="tns:setImageResolution" /> >> >> >> >> >> >> >> ....... >> >> >> name="parameters"> >> >> >> ...... >> >> >> name="setImageResolution"> >> >> ...... >> >> >> style="document" /> >> >> >> >> >> >> >> >> >> >> On May 22, 2008, at 11:46 AM, Jo wrote: >> >>> In my java interface, I have the following > annotated >>> method: >>> >>> >>> @WebMethod(operationName = "setImageResolution", >>> action = "urn:setImageResolution") >>> @Oneway >>> public void setImageResolution(@WebParam(name = >>> "width", header = false) >>> int width, @WebParam(name = "height", header = >> false) >>> int height); >>> >>> The following is the generated WSDL with both CXF >>> 2.1.0 and 2.1.1, >>> >>> >>> >>> style="document" /> >>> >>> >>> >>> >>> >>> WSDL generated in XFire: >>> >>> - >>> - >>> - >>> >>> name="width" type="xsd:int" /> >>> >>> name="height" type="xsd:int" /> >>> >>> >>> >>> >>> - >>> - >>> >>> message="tns:setImageResolutionRequest" /> >>> >>> >>> With CXF, the generated WSDL doesn't include my >>> @Webparam information? Why? and how can I generate >>> wsdl with xsd information? >>> >>> >>> >>> >> >> --- >> Daniel Kulp >> [EMAIL PROTECTED] >> http://www.dankulp.com/blog >> >> >> >> >> >> >> >> >> > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > > > > > --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
