cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r923499 - in /websites/production/cxf/content: cache/main.pageCache grouping-bundles-to-applications-in-osgi.html
Date Thu, 25 Sep 2014 08:46:51 GMT
Author: buildbot
Date: Thu Sep 25 08:46:50 2014
New Revision: 923499

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/main.pageCache
    websites/production/cxf/content/grouping-bundles-to-applications-in-osgi.html

Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/grouping-bundles-to-applications-in-osgi.html
==============================================================================
--- websites/production/cxf/content/grouping-bundles-to-applications-in-osgi.html (original)
+++ websites/production/cxf/content/grouping-bundles-to-applications-in-osgi.html Thu Sep
25 08:46:50 2014
@@ -99,7 +99,7 @@ Apache CXF -- Grouping bundles to applic
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><h2 id="GroupingbundlestoapplicationsinOSGi-Usecase:Deployingmorethanonemodularapplicationintothesameframework">Use
case: Deploying more than one modular application into the same framework</h2><p>In
OSGi the best practice is to split an application into several bundles that each cover a different
business aspect of the application. So imagine an application for a service layer of a web
shop with bundles for :</p><ul style="list-style-type: square;"><li>browsing
articles</li><li>cart management</li><li>checkout</li><li>customer</li></ul><p>Each
of the above bundles would like to offer and consume 0..n cxf services. Still there would
be common aspects. All of the services require basic auth with user / password from an ldap
server, the requests / replies should be logged to a database.</p><p>So it would
make sense to define the common aspects only once (either on servlet or cxf bus level).</p><p>At
the same time we might have a second application that also
  provides some bundles but that has different common rules.</p><p>So we need
a way to group the bundles together to one application so the common rules can be applied
while distinguishing between the different applications.</p><p>This use case does
not map well to the way cxf can be configured in OSGi.</p><h2 id="GroupingbundlestoapplicationsinOSGi-CurrentsolutionsfortheservlettransportinOSGi">Current
solutions for the servlet transport in OSGi</h2><p>In OSGi there are two ways
to use the CXF servlet transport.</p><h3 id="GroupingbundlestoapplicationsinOSGi-UsingthedefaultCXFservlet">Using
the default CXF servlet</h3><p>This works by simply using an address like "/mypath".
The endpoint will then be on /cxf/mypath. In this approach is that there is only one servlet
for the OSGi framework. All endpoints defined in all bundles will only use this servlet. So
does not work well if you have two applications that would like to configure the servlet with
specially e.g in regard to security.
 </p><h3 id="GroupingbundlestoapplicationsinOSGi-Usingawebapplicationbundle">Using
a web application bundle</h3><p>Inside the web application bundle you can define
a CXF servlet. The servlet endpoints defined in this bundle will then be available on the
servlet. So this allows to define more than one servlet per OSGi framework. The CXFBlueprintServlet
allows to connect the servlet to a blueprint context that defines the endpoints. The problem
here is that it does not covert the case where several bundles of the application would like
to define CXF endpoints.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Currentsolutionforsharingrules">Current
solution for sharing rules</h2><p>CXF will pick up all features that are exposed
as an OSGi service. So this allows to define common rules but the rules apply to all bundles
in the framework.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Idea:DefinetheCXFbusonceperapplicationasOSGiservice">Idea:
Define the CXF bus once per application as OSGi 
 service</h2><p>Currently the cxf bus in OSGi is defined per bundle. So if each
bundle has one blueprint context then cxf will automatically create one bus per bundle.</p><p>So
the idea is to define the cxf bus in one bundle and export it as an OSGi service with the
name of the application as identifier. This already works by simply defining a &lt;cxf:bus
id="myapplication"/&gt;. The bus is also automatically exposed as an OSGi service by cxf.</p><p>Each
of the other bundles of the application could then refer to this bus and add its endpoints
to it.I am not sure how this would work with the OSGi ifecycle where bundles can be added
and removed at any time though.</p><p>The advantage would be that in the bundle
defining the bus all the common rules could be applied. So the other bundles do not have to
repeat that step.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Alternativelynametheservletintheendpoint">Alternatively
name the servlet in the endpoint</h2><p>If we give each servlet /
  DestinationRegistry a name then we could refer to this name in the endpoint. So the user
could choose, which servlet to wire to. The DestinationRegistry could be exported in OSGi
as a Service with the name in a property.In the endpoint we could e.g. use the following uri
syntax: servlet:servletname/path. The endpoint would then be published to the DestinationRegistry
with the given name.</p><p>TODO: How to store the DestinationRegistries in non
OSGi environments.</p><p>&#160;</p><p>&#160;</p><p>&#160;</p></div>
+<div id="ConfluenceContent"><h2 id="GroupingbundlestoapplicationsinOSGi-Usecase:Deployingmorethanonemodularapplicationintothesameframework">Use
case: Deploying more than one modular application into the same framework</h2><p>In
OSGi the best practice is to split an application into several bundles that each cover a different
business aspect of the application. So imagine an application for a service layer of a web
shop with bundles for :</p><ul style="list-style-type: square;"><li>browsing
articles</li><li>cart management</li><li>checkout</li><li>customer</li></ul><p>Each
of the above bundles would like to offer and consume 0..n cxf services. Still there would
be common aspects. All of the services require basic auth with user / password from an ldap
server, the requests / replies should be logged to a database.</p><p>So it would
make sense to define the common aspects only once (either on servlet or cxf bus level).</p><p>At
the same time we might have a second application that also
  provides some bundles but that has different common rules.</p><p>So we need
a way to group the bundles together to one application so the common rules can be applied
while distinguishing between the different applications.</p><p>This use case does
not map well to the way cxf can be configured in OSGi.</p><h2 id="GroupingbundlestoapplicationsinOSGi-CurrentsolutionsfortheservlettransportinOSGi">Current
solutions for the servlet transport in OSGi</h2><p>In OSGi there are two ways
to use the CXF servlet transport.</p><h3 id="GroupingbundlestoapplicationsinOSGi-UsingthedefaultCXFservlet">Using
the default CXF servlet</h3><p>This works by simply using an address like "/mypath".
The endpoint will then be on /cxf/mypath. In this approach is that there is only one servlet
for the OSGi framework. All endpoints defined in all bundles will only use this servlet. So
does not work well if you have two applications that would like to configure the servlet with
specially e.g in regard to security.
 </p><h3 id="GroupingbundlestoapplicationsinOSGi-Usingawebapplicationbundle">Using
a web application bundle</h3><p>Inside the web application bundle you can define
a CXF servlet. The servlet endpoints defined in this bundle will then be available on the
servlet. So this allows to define more than one servlet per OSGi framework. The CXFBlueprintServlet
allows to connect the servlet to a blueprint context that defines the endpoints. The problem
here is that it does not covert the case where several bundles of the application would like
to define CXF endpoints.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Currentsolutionforsharingrules">Current
solution for sharing rules</h2><p>CXF will pick up all features that are exposed
as an OSGi service. So this allows to define common rules but the rules apply to all bundles
in the framework.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Idea:DefinetheCXFbusonceperapplicationasOSGiservice">Idea:
Define the CXF bus once per application as OSGi 
 service</h2><p>Currently the cxf bus in OSGi is defined per bundle. So if each
bundle has one blueprint context then cxf will automatically create one bus per bundle.</p><p>So
the idea is to define the cxf bus in one bundle and export it as an OSGi service with the
name of the application as identifier. This already works by simply defining a &lt;cxf:bus
id="myapplication"/&gt;. The bus is also automatically exposed as an OSGi service by cxf.</p><p>Each
of the other bundles of the application could then refer to this bus and add its endpoints
to it.I am not sure how this would work with the OSGi ifecycle where bundles can be added
and removed at any time though.</p><p>The advantage would be that in the bundle
defining the bus all the common rules could be applied. So the other bundles do not have to
repeat that step.</p><h2 id="GroupingbundlestoapplicationsinOSGi-Alternativelynametheservletintheendpoint">Alternatively
name the servlet in the endpoint</h2><p>If we give each servlet a
  name then we could refer to this name in the endpoint. So the user could choose, which servlet
to wire to. In the endpoint we could e.g. use the following uri syntax: servlet:servletname/path.
The endpoint would then be published to the DestinationRegistry with the given name.</p><p>TODO:
How to store the DestinationRegistries in non OSGi environments.</p><p>&#160;</p><p>&#160;</p><p>&#160;</p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message