felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r943067 - in /websites/staging/felix/trunk/content: ./ documentation/subprojects/apache-felix-dependency-manager-4/guides/ documentation/subprojects/apache-felix-dependency-manager-4/guides/diagrams/
Date Mon, 09 Mar 2015 20:53:13 GMT
Author: buildbot
Date: Mon Mar  9 20:53:13 2015
New Revision: 943067

Log:
Staging update by buildbot for felix

Modified:
    websites/staging/felix/trunk/content/   (props changed)
    websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/design-patterns.html
    websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/diagrams/adapter.png
    websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/diagrams/aspect.png

Propchange: websites/staging/felix/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Mar  9 20:53:13 2015
@@ -1 +1 @@
-1665351
+1665356

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/design-patterns.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/design-patterns.html
(original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/design-patterns.html
Mon Mar  9 20:53:13 2015
@@ -75,7 +75,7 @@
 <h4 id="motivation">Motivation</h4>
 <p>In a dynamic framework, services can come and go. Components that publish a service
are often themselves dependent on other services to perform their task. In such cases, they
have a dependency on those services and it makes sense to only publish their own services
when these dependencies are available. Being able to declare such dependencies in code ensures
consistent life cycle behavior.</p>
 <h4 id="structure">Structure</h4>
-<p><img alt="Singleton pattern" src="diagrams/singleton.png" /></p>
+<p><img src="./diagrams/singleton.png" alt="Singleton" style="width: 190px"/></p>
 <h4 id="code-example">Code Example</h4>
 <div class="codehilite"><pre><span class="n">public</span> <span
class="n">class</span> <span class="n">Activator</span> <span class="n">extends</span>
<span class="n">DependencyActivatorBase</span> <span class="p">{</span>
     <span class="n">public</span> <span class="n">void</span> <span
class="n">init</span><span class="p">(</span><span class="n">BundleContext</span>
<span class="n">context</span><span class="p">,</span> <span class="n">DependencyManager</span>
<span class="n">manager</span><span class="p">)</span> <span class="n">throws</span>
<span class="n">Exception</span> <span class="p">{</span>
@@ -103,7 +103,7 @@
 <h4 id="motivation_1">Motivation</h4>
 <p>In aspect oriented programming, supporting functions are isolated from the main
application's business logic. This increases modularity at the source level by allowing the
separation of cross-cutting concerns. In OSGi we want to extend this modularity to the runtime,
therefore we implement aspects to work on certain services, where the aspect itself publishes
that same service but (usually) with a higher priority. This allows you to dynamically add
and remove aspects.</p>
 <h4 id="structure_1">Structure</h4>
-<p><img alt="Aspect pattern" src="diagrams/aspect.png" /></p>
+<p><img src="./diagrams/aspect.png" alt="Aspect" style="width: 190px"/></p>
 <h4 id="code-example_1">Code Example</h4>
 <div class="codehilite"><pre><span class="n">public</span> <span
class="n">class</span> <span class="n">Activator</span> <span class="n">extends</span>
<span class="n">DependencyActivatorBase</span> <span class="p">{</span>
     <span class="n">public</span> <span class="n">void</span> <span
class="n">init</span><span class="p">(</span><span class="n">BundleContext</span>
<span class="n">context</span><span class="p">,</span> <span class="n">DependencyManager</span>
<span class="n">manager</span><span class="p">)</span> <span class="n">throws</span>
<span class="n">Exception</span> <span class="p">{</span>
@@ -135,7 +135,7 @@
 <h4 id="motivation_2">Motivation</h4>
 <p>Like with aspects, sometimes you want to create adapters for certain services, which
add certain behavior that results in the publication of (in this case) a different service.
Adapters can dynamically be added and removed and allow you to keep your basic services implementations
clean and simple, adding extra features on top of them in a modular way. </p>
 <h4 id="structure_2">Structure</h4>
-<p><img alt="Adapter pattern" src="diagrams/adapter.png" /></p>
+<p><img src="./diagrams/adapter.png" alt="Adapter" style="width: 190px"/></p>
 <h4 id="code-example_2">Code Example</h4>
 <div class="codehilite"><pre><span class="n">public</span> <span
class="n">class</span> <span class="n">Activator</span> <span class="n">extends</span>
<span class="n">DependencyActivatorBase</span> <span class="p">{</span>
     <span class="n">public</span> <span class="n">void</span> <span
class="n">init</span><span class="p">(</span><span class="n">BundleContext</span>
<span class="n">context</span><span class="p">,</span> <span class="n">DependencyManager</span>
<span class="n">manager</span><span class="p">)</span> <span class="n">throws</span>
<span class="n">Exception</span> <span class="p">{</span>
@@ -169,7 +169,7 @@
 <h4 id="motivation_3">Motivation</h4>
 <p>Resource adapters are similar to normal adapters, but instead of requiring a service,
they require a resource and provide a service on top of it. Resources are an abstraction that
is introduced by the dependency manager, represented as a URL. They can be implemented to
serve resources embedded in bundles, somewhere on a file system or in a content repository
or database.</p>
 <h4 id="structure_3">Structure</h4>
-<p><img alt="ResourceAdapter pattern" src="diagrams/resourceadapter.png" /></p>
+<p><img src="./diagrams/resourceadapter.png" alt="Singleton" style="width: 180px"/></p>
 <h3 id="temporal-dependency">Temporal Dependency</h3>
 <p>Provides a proxy that hides the service dynamics of a dependency, even if it disappears
for a short time.</p>
 <h4 id="motivation_4">Motivation</h4>
@@ -186,7 +186,7 @@
 <p>The traditional model for dealing with listeners in Java needlessly complicates
things in an OSGi context. Instead of having listeners registering themselves with the component
that will invoke them on any change, a listener simply registers itself in the service registry
and the component will do a lookup of all relevant services. This is explained in more detail
on the OSGi.org wiki in the <a href="http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf">"Listeners
considered harmful: the 'whiteboard' pattern"</a> article.</p>
 <h4 id="structure_6">Structure</h4>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1665333 by uiterlix on Mon, 9 Mar 2015 19:57:18 +0000
+        Rev. 1665356 by uiterlix on Mon, 9 Mar 2015 20:52:57 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/diagrams/adapter.png
==============================================================================
Binary files - no diff available.

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/guides/diagrams/aspect.png
==============================================================================
Binary files - no diff available.



Mime
View raw message