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.
Christian
On 25.09.2014 14:47, Daniel Kulp wrote:
On Sep 25, 2014, at 3:51 AM, Christian Schneider <[email protected]>
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
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
