cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
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 12:47:27 GMT

On Sep 25, 2014, at 3:51 AM, Christian Schneider <chris@die-schneider.net> 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


> 
> I have a slightly different idea that would also help with https://issues.apache.org/jira/browse/CXF-5410
.
> 
> How about giving each servlet a name and refer the name in the endpoint uri. like servlet:servletname/path.
This would make the endpoint uri more self describing and also
> nearer to the camel syntax. Using such a uri the user could even have one bundle that
exposes endpoints to two different servlet if he needs. We could still keep the uri /path
for compatibility which would
> map to the default servlet. So people do not have to change their uris right now.
> 
> See the wiki page for details: https://cwiki.apache.org/confluence/display/CXF/Grouping+bundles+to+applications+in+OSGi
> 
> This scheme should work fine with the way we share the DestinationRegistry in OSGi. In
fact I think I missed the chance to give the servlet a name in the original design of the
servlet path.
> 
> WDYT ?
> 
> Christian
> 
> 
> On 24.09.2014 15:12, Sergey Beryozkin wrote:
>> On 24/09/14 13:42, Christian Schneider wrote:
>>> I would like to deploy two (or more) CXF based applications into the
>>> same OSGi framework.
>>> How can I enforce common rules per application while keeping the
>>> applications separate from each other?
>>> 
>>> I created a wiki page to show the scenario and describe current
>>> approaches I found and their limitations as well as an idea for a new
>>> approach.
>>> I would be happy about any feedback. Did you have a similar case? How
>>> did you solve it?
>> 
>> Re the application example at the wiki, what about having 4 war bundles, each containing
its own servlet with n endpoints, as per the text "Each of the above bundles would like to
offer and consume 0..n cxf services".
>> 
>> As per the common configuration, the HTTP context to which these servlets are bound
can have some base common configuration.
>> 
>> Furthermore, each servlet would have its own configuration shared by those n endpoints
bound to this servlet.
>> 
>> Finally, each CXF servlet can have a bus parameter injected into it, so this is the
extra opportunity to share the parameters among the group of endpoints (via the bus, as you
mentioned)
>> 
>> Sergey
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message