It's coded by CXF that way (obviously) and may have changed from earlier
CXF versions. It normally shouldn't matter, and I agree that Tomcat
couldn't be the issue. Using the "PortType" extension on the interface
is helpful for newbies, as it emphasizes that that information comes
from the wsdl:portType element, which is the web service interface, not
its wsdl:binding which is the implementation of that interface.
The wsdl2java "-sn" setting:
http://cxf.apache.org/docs/wsdl-to-java.html can be used to generate a
different service name if helpful for plugging into your existing
client-side code.
HTH,
Glen
On 08/18/2013 09:17 AM, David Hoffer wrote:
Hi Glen,
First I'd like to say...that's a really great blog site you have. So much
information, I which I'd known about that, I'll be sure to reference this
going forward.
Regarding WSDL first, yeah I think I understand why, since it's the
contract its best to start there and build out from that. However my
confidence level of getting all the details right in a custom WSDL is not
100% so I've always preferred to start with Java which is fully known and
let the tools build out from there....but get your point its not as ideal.
I did get it working...WSDL in Tomcat deployed as war but I do have a
question...and I think I've seen this before but not sure why. This time,
in the Tomcat app, when I build the client (test app) using the
cxf-codegen-plugin's wsdl2java goal...the client code is different than in
previous CXF apps that I've made that are hosted with embedded Jetty (but I
don't think the container is the issue).
Specifically what's different is the names of the interface and
implementation classes. Previously I'd get a service interface name that
exactly matches what it is called in the server and then the implementation
class just appends Service to that name (and it extends Service). All this
makes sense to me.
However with the new Tomcat hosted one, the interface name has PortType
appended to it and the implementation class as the exact name of my actual
service interface name. This seems odd to me. Any idea why the names are
different?
Thanks,
-Dave
On Sat, Aug 17, 2013 at 10:13 PM, Glen Mazza <[email protected]> wrote:
http://www.jroller.com/gmazza/**entry/blog_article_index<http://www.jroller.com/gmazza/entry/blog_article_index>:
Blog article #3 (but hopefully eventually #2 for you as I always recommend
WSDL-first).
Glen
On 08/17/2013 12:23 AM, David Hoffer wrote:
I have a CXF webservice that I need to now host in Tomcat webapp. I'm
using the 'code first' approach where I have Java pojos, annotated for CXF
webservice, e.g.
@WebService()
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
SOAPBinding.Use.LITERAL)
@XmlJavaTypeAdapter(**WebServiceAPIAdapter.class)
public interface IWebServiceAPI {
public WebOutput calc(@WebParam(name = "webInput") WebInput
webInput);
}
Which previously I hosted in standalone Jetty server, e.g.
WebServiceAPI implementor = new WebServiceAPI();
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceClass(**IWebServiceAPI.class);
svrFactory.setAddress("http://**IP:port/namespace";);
svrFactory.setServiceBean(**implementor);
server = svrFactory.create();
That all works well but now I need to do the same in Tomcat, so I assume
the code and @WebService annotation is the same? But how do I now
host/deploy this in war? E.g. I don't need any server with IP
address/etc.
Rather I want to deploy in war so IP:port is already defined by the
container just need the rest of this.
How do I transition to Tomcat/war?
Also I might mention that I need the resulting auto generated WSDL to
generate schema for the WebOutput result object as that is a nested Java
POJO...again this works fine in standalone Jetty server just need the same
in war.
