On Tue October 6 2009 3:50:42 pm warrior389 wrote: > I'm using servicemix (fuse 4.1.0.2) with cxf 2.2.2.1-fuse and the cxf osgi > transport 4.1.0.2-fuse on a windows machine with jdk 6u16. > > I'm trying to make a simple jaxws service like the servicemix > http://servicemix.apache.org/SMX4/cxf-examples.html cxf-osgi example . > Something like: > > <jaxws:endpoint > id="helloWorld" > implementor="org.apache.servicemix.examples.cxf.HelloWorldImpl" > address="/HelloWorld"/> > > and the WebService annotations are simple. Just @WebService on the > @WebService(endpointInterface = > "org.apache.servicemix.examples.cxf.HelloWorld") on the implementation. > > The example page I linked earlier says that the service should be published > at http://localhost:8080/cxf/HelloWorld?wsdl, but for me its at a different > port, http://localhost:8181/cxf/HelloWorld?wsdl. I had to netstat to find > what port it was listening on. I can access the WSDL fine and exercise it > with SoapUI, and the example client.
Well, this really depends on which http transport you use and the container it's deployed in (if any). There really are three options: 1) The "built in" http-jetty HTTP transport. In this case, the "address" in the config would be a full address (like http://localhost:8080/HelloWorld";) and we would bring up Jetty on that exact port and stick the endpoint at that exact address. We control everything and can do this. With the sample you mentioned above, if you change the <import> in the config from the osgi http to the cxf-extension-http-jetty.xml file, this should work (providing jetty bundles are available) 2) Servlet transport - in this case, a separate servlet engine is providing the http capabilities and a servlet is registered to handle things. In this case, the port is completely controlled by the servlet engine (like tomcat defaults to 8080). Also, the application context and servlet context are controlled by the war name and the config in the web.xml. The servlet (and thus us), have no control over that. What worse, we don't even know those things until request time. In this case, the address is like above ("/HelloWorld"), but the full url is the based on the host/port configured in the servlet container + the app context (normally the war name) + servlet context (configured in the wars web.xml) + the above address. Example: http://localhost:8080/myapp/services/HelloWorld 3) OSGi transport - this is what you are using above. It's very similar to the servlet transport. The port is controlled by the osgi container. In your case, smx defaults to 8181. The context currently is hard coded to "cxf", but with 2.2.4, we've moved the OSGI transport from smx into cxf and added some OSGI config service things for it so you can change that. > So, I have four questions: > 1. Why is the port different (8080 vs 8181), and how is it determined? > 2. Why is the service at /cxf/HelloWorld, when the jaxws endpoint > definition said it is at /HelloWorld? I assume some kind of cxf context is > prepended, but how is this controlled and where? And can I override it in > my service configuration, either spring or annotation? See above. > 3. This is probably the most important. How can my service know what its > actual location is? Even if I grab the WebServiceContext using a @Resource > annotation, it only gives me an address of /HelloWorld, not the full > http://localhost:8181/cxf/HelloWorld?wsdl. I want to be able to register > the service in UDDI. UNFORTUNATLY, due to limitations in the Servlet specs and such, there is not a way to know it until the first time someone actually hits the service. :-( What's worse, it can be different from request to request. For example, the container can be configured to listen on both 8080 and 9090 and requests can come in from both. Dan > 4. If I change the address from /HelloWorld to nmr:HelloWorld, how would > the service know its endpoint? -- Daniel Kulp [email protected] http://www.dankulp.com/blog
