Hello Sergey, hello Dan! Thanks for your responses. In the meantime, we changed the service URL's in our service which now has a servicePath: http:// <server>:<port>/servicePath/serviceName
But now we are struggling with another "issue": Imagine you provide a web service ServiceA (JAX-WS based on CXF bean definition) for customer CustomerA and a service ServiceB for customer CustomerB. If we use the HTTP OSGI service, we do not have the possibility to hide ServiceA for CustomerB and ServiceB for CustomerA, do we have? We couldn't figure it out how... I think we need the possibility to bind a service (CXF bean) to a specific port. In this case, we can make sure only CustomerA can access this port and only see the services which are designed for him (using client/server certificates configured in jetty.xml). We could do than the same for CustomerB which should only see ServiceB... Any thoughts? Best, Christian On Fri, Jun 1, 2012 at 2:02 PM, Sergey Beryozkin <[email protected]>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<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. >> > > >
