Hi Christian, Willem's suggestion is correct. I have implemented your use case in the past and found sing the OSGi HTTP Service to deploy CXF WS instances to restrictive. Using Camel to act as the HTTP Proxy to the Beans or Services offers far more flexibility.
In addition to being able to proxy, It also comes with the added benefit of fine grained configuration management using the containers config admin service which I found a huge advantage. Now I could stop, start and tune individual WS instances and not worry about bringing all my services down just to manage one. Just my two cents. I really need to document this. Time for a new blog entry. :) Best Regards, Scott ES On Sat, Jun 2, 2012 at 10:20 PM, Willem Jiang <willem.ji...@gmail.com>wrote: > Maybe you can setup some kind of proxy to delegate the request to a right > service. > In this way CustomerB service will not be accessed by CustomerA. > > > On Sun, Jun 3, 2012 at 6:02 AM, Christian Müller < > christian.muel...@gmail.com> wrote: > > > 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 <sberyoz...@gmail.com > > >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. > > >> > > > > > > > > > > > > -- -- Scott England-Sullivan ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://sully6768.blogspot.com Twitter: sully6768
