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.