Actually, I think there is a bug with using the methods on the impl 
instead of the interface.    I ran into something very similar today 
while writing a testcase for CXF-655.   I just didn't have time to 
investigate as CXF-655 was troublesome enough.     I'll dig into it more 
tomorrow.


Dan




On Wednesday 18 July 2007 18:10, Dan Diephouse wrote:
> Hi Stuart,
> Did you specify a @WebService(endpointInterface="...YourInterface") on
> the implementation class? You're using the JAX-WS frontend and per the
> JAX-WS spec, thats how its supposed to work :-)
>
> Cheers,
> - Dan
>
> On 7/18/07, Stuart Bingë <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > We've been using XFire (specifically its SOAP transport) together
> > with JSR-181
> > annotations for some time now in our internal Spring-based web
> > services (hosted in Tomcat), and are now in the process of looking
> > to upgrade to CXF
> > as part of a general systems upgrade. The web services are
> > "java-first", where we code to a SEI and then rely on XFire to
> > generate the WSDL as appropriate. In addition, the SOAP binding used
> > is RPC/Literal for interoperability with PHP clients.
> >
> > After following the "Writing a service with Spring" article on the
> > CXF site
> > (http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
> >), as well as attempting the basic "HelloWorld" applet that the
> > article describes
> > (i.e. separate from our existing environment/services), I've
> > discovered some
> > strange behaviour that wasn't present with XFire.
> >
> > When exposing an endpoint via <jaxws:endpoint ... />, the generated
> > WSDL appears to be coming from the implementation class rather than
> > the service interface -- i.e. getters and setters for
> > implementation-specific properties
> > are included in the WSDL.
>
> Is this the expected behaviour with <jaxws:endpoint />? If so, what
> other
>
> > methods are available/recommended for exposing an endpoint via an
> > interface
> > rather than an implementation object?
>
> This can be solved with @WebMethod(ignore = true) annotations on the
>
> > implementation class, but obviously this isn't ideal and shouldn't
> > be needed
> > in the first place. We'd like to continue just exposing the
> > interface as the
> > service contract and then be able to implement the service in
> > whatever way we
> > deem fit.
> >
> > Any pointers would be greatly appreciated!
> >
> > Cheers,
> > --
> > Stuart Bingë
> >
> > ____________________________________________________________________
> >__
> >
> > "Complinet Ltd is registered in England. Registered office at
> > Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Company
> > number 3170722. VAT No. 749 324 021.
> > Complinet Inc is a corporation registered in Delaware, USA."
> >
> > This email has been scanned by the MessageLabs Email Security
> > System.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to