wsdlLocation removed from demo's impl code?

["Liu, Jervis" <jl...@iona.com>]

Hi,

I am currently looking into CXF-584 (hello_world sample (Running demo with HTTP Get section) doesn't work), the cause of this problem is because wsdlLocation attribute was removed from server's impl code (take a look into GreeterImpl.java). We now load server side service module from class instead of from WSDL. While we will keep fixing bugs discovered in code-first approach, I still like to see our demos building service module from WSDL by default, in order to be consistent with previous behaviors. Before I put back the wsdlLocation, can someone shed some light on why wsdlLocation was removed?  I just vaguely remembered this is related to some WSDL path resolving issues.

Thanks,
Jervis

Re: wsdlLocation removed from demo's impl code?

[Daniel Kulp <dk...@apache.org>]

Jervis and James,

The wsdlLocation was removed from the generated SEI interface, not the 
impl.   I'm not sure if it was ever generated into the impl.   I don't 
really know.    In anycase, this was to make the generated SEI 
more "portable" (usable on client and server side where paths to wsdl's 
would be very different) as well as make it more consistent with code 
generated from the JAX-WS RI which makes porting apps from the RI to CXF 
easier.


On Tuesday 24 April 2007 03:04, James Mao wrote:
> Add the wsdlLocation attribute into the annotation, is the easiest way
> to fix the problem.
> However we can raise two issues:
>
> * Why in jaxws case, the buildFromWsdl and buildFromClass generate two
> different results

That's a good question.   Probably some bugs someplace.  :-(

> * Besides jaxws annotation, is there another way to select
> specifically from wsdl/class

Kind of....   For the server side, the jaxws spec allows you to pass the 
wsdl into the endpoint via the endpoint.setMetadata(List<Source>) call.   
However, I don't think that's implemented yet.   :-(

In CXF, we have a "hidden" method (the yoko tests use this):

You can call: 
endpoint.getProperies().set("javax.xml.ws.wsdl.description", "path/to/wsdl");
before calling publish to set the wsdlLocation that is used.

Dan


> James.
>
> > Hi,
> >
> > I am currently looking into CXF-584 (hello_world sample (Running
> > demo with HTTP Get section) doesn't work), the cause of this problem
> > is because wsdlLocation attribute was removed from server's impl
> > code (take a look into GreeterImpl.java). We now load server side
> > service module from class instead of from WSDL. While we will keep
> > fixing bugs discovered in code-first approach, I still like to see
> > our demos building service module from WSDL by default, in order to
> > be consistent with previous behaviors. Before I put back the
> > wsdlLocation, can someone shed some light on why wsdlLocation was
> > removed?  I just vaguely remembered this is related to some WSDL
> > path resolving issues.
> >
> > Thanks,
> > Jervis

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

Re: wsdlLocation removed from demo's impl code?

[James Mao <ja...@iona.com>]

Add the wsdlLocation attribute into the annotation, is the easiest way 
to fix the problem.
However we can raise two issues:

* Why in jaxws case, the buildFromWsdl and buildFromClass generate two 
different results
* Besides jaxws annotation, is there another way to select specifically 
from wsdl/class

James.
> Hi,
>
> I am currently looking into CXF-584 (hello_world sample (Running demo with HTTP Get section) doesn't work), the cause of this problem is because wsdlLocation attribute was removed from server's impl code (take a look into GreeterImpl.java). We now load server side service module from class instead of from WSDL. While we will keep fixing bugs discovered in code-first approach, I still like to see our demos building service module from WSDL by default, in order to be consistent with previous behaviors. Before I put back the wsdlLocation, can someone shed some light on why wsdlLocation was removed?  I just vaguely remembered this is related to some WSDL path resolving issues.
>
> Thanks,
> Jervis
>
>