cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: How to handle "applications" in OSGi that offer / consume cxf services and want to enforce application level rules
Date Thu, 25 Sep 2014 14:16:17 GMT
The filter approach is generally a good technique as it allows us more 
flexibility. It has some drawbacks though.

The main issue for me is naming. If you have one servlet per application 
you can name it like the application. The endpoint uris then only have 
to be unique inside the application. If each endpoint has a complete uri 
then people have to make sure it is globally unique. Normally they will 
then introduce a prefix to the path like the application name. The 
drawback is that this name is then littered all over the application 
bundles. So if you want to change the url you have to change many places.

The approach of one servlet per endpoint has the same drawbacks.

In general both approaches have the problem that the user can not easily 
configure the servlet / filter in some useful granularity like per 
application. On the other hand I am not sure how much such configuration 
is really necessary as most configs can also be done on the cxf 
interceptor level.


On 25.09.2014 14:47, Daniel Kulp wrote:
> On Sep 25, 2014, at 3:51 AM, Christian Schneider <> wrote:
>> Having one servlet per bundle would definately work.
>> I see two problems though:
>> - Each servlet has its own base path where all services reside then. Not necessarily
a bad thing but it would limit the freedom of the user to define where his endpoints live.
>> - Added configuration overhead and complexity: Each of the bundles has to be a web
application bundle with a web config and servlet definition.
> Personally, with Karaf 2.4/3.0, I’d prefer we just get a filter in place instead of
the servlet and then the whole “context” part is irrelevant.   People could deploy the
service at /a/b from one bundle, /c/d from another, etc…   Most of the problem goes away.
  Either that or NOT register a single servlet at start and instead register an OSGi service
that the HTTP Transport could use in OSGi that would register an individual per-endpoint servlet
during publish.
> The only major issue is the /services link.   There is a question of whether there should
be a global services link, per bundle,  etc….   For that, I’d LIKE to pull the services
generation stuff completely out of the servlet and make an Endpoint specifically for it. 
 (Like a REST Endpoint or something) that the user could register on whatever URL they want
(or not register at all).    Possibly per-bundle service listing, etc...
> Dan

Christian Schneider

Open Source Architect

View raw message