This is something I've been tossing around in my head a bit. (Way too many things being tossed around in there) One thought I had was to adapt the CXF Servlet to possibly be a Filter instead of a servlet (well, have a filter and a servlet or something). Thus, it could filter on "/*" and just process the requests it knows about and pass the rest onto the next filter/servlet. In OSGi, we could register the filter instead of the servlet.
Dan On Friday, June 01, 2012 01:02:28 PM Sergey Beryozkin wrote: > Hi Christian > > Sorry for a delay, > > On 02/03/12 10:18, cmueller wrote: > > We deployed some Camel (2.6.0) routes which provides some JAX WS web > > services via CXF (2.3.3) into ServiceMix (4.3.1). In the present > > implementation we use "complete" URLs like > > "http://<server>:<port>/serviceName". Everything works well so far. > > Now, we want to benefit from the HTTP OSGI service. After the required > > changes, everything still works well in principal. The only change we > > are > > try to avoid is the changed service URL. The service in now available > > with the URL "http://<server>:<port>/cxf/serviceName". We didn't want > > to tell all our (internal) clients to change the URL. So, we created > > the file $SMX_HOME/etc/org.apache.cxf.osgi.cfg with the following > > entry: > > org.apache.cxf.servlet.context=/ > > It didn't work (we received a page from Jetty with all available > > services if we request "http://<server>:<port>/serviceName"). > > Than we tried: > > org.apache.cxf.servlet.context= > > It also didn't work (we received a HTTP 404 response code if we request > > "http://<server>:<port>/serviceName"). > > > > Any other idea to get this working or is this not possible / not > > supported at the moment / a very bad idea / ... > > I was curious myself whether it would work or not so I finally ended up > debugging a bit into the pax-web code. > For a start I think having a context like "/" set for CXF-enabled > endpoints will most likely interfere with other bundles which may offer > their own HTTP endpoints, for example, when Karaf starts, a webconsole > feature registers a "/system/console" context, so a "/" context would > catch the requests targeted at the webconsole feature. I temporarily > removed a webconsole from the list of start-up features, but having "/" > did not succeed anyway, > > I was not really pursuing why, most likely it would conflict with the > DefaultHttpContext. That could've been explored further but as I said it > will most likely be not accepted due to possibility of such a context > interfering with the other HTTP-aware bundles. I think it might be a > minor bug in pax-web that "" and "/" context values are treated > differently but the end result is effectively the same. > > So suppose you have "http://<server>:<port>/serviceName" and you do not > want to introduce an extra segment, like "/cxf" (default) or > "/services", etc. > > Then I guess you should set "org.apache.cxf.servlet.context=serviceName" > and adjust the jaxws endpoint address attribute to "/". That will work > but only for a given serviceName value > > Cheers, Sergey > > > Thanks in advance, > > Christian > > > > -- > > View this message in context: > > http://cxf.547215.n5.nabble.com/changing-context-path-in-OSGI-from-cxf- > > to-tp5530551p5530551.html Sent from the cxf-user mailing list archive at > > Nabble.com. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
