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.
