On Wed October 21 2009 11:10:27 am skarootz wrote: > Ok, then you say it is possible to change the context "cxf" after 2.2.4, > but how is it done?
See the thread: http://www.nabble.com/Use-of-OSGi-http-service-instead-of-jetty-engine-to25965535.html Dan > > dkulp wrote: > > 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
