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 > > 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
