On 01/06/12 16:27, Daniel Kulp wrote:
This is something I've been tossing around in my head a bit. (Way too many
things being tossed around in there)
LOL
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.
That should work indeed.
Cheers, Sergey
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.
