Author: buildbot
Date: Sat Oct 19 08:17:14 2013
New Revision: 883258
Log:
Staging update by buildbot for openwebbeans
Modified:
websites/staging/openwebbeans/trunk/content/ (props changed)
websites/staging/openwebbeans/trunk/content/openwebbeans-spi.html
Propchange: websites/staging/openwebbeans/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Oct 19 08:17:14 2013
@@ -1 +1 @@
-1533700
+1533705
Modified: websites/staging/openwebbeans/trunk/content/openwebbeans-spi.html
==============================================================================
--- websites/staging/openwebbeans/trunk/content/openwebbeans-spi.html (original)
+++ websites/staging/openwebbeans/trunk/content/openwebbeans-spi.html Sat Oct
19 08:17:14 2013
@@ -75,16 +75,17 @@
<div id="OwbContent_" class="wiki-content">
<h1 id="openwebbeans-spi">OpenWebBeans SPI</h1>
-<h3 id="what-is-an-spi">What is an SPI?</h3>
+<h2 id="what-is-an-spi">What is an SPI?</h2>
<blockquote>
<p>Service Provider Interface (SPI) is an API intended to be implemented
or extended by a third party. It can be used to enable framework
extension and replaceable components.
- <a
href="http://en.wikipedia.org/wiki/Service_provider_interface";>wikipedia</a></p>
</blockquote>
-<h3 id="how-does-the-spi-functionality-work-in-openwebbeans">How does the SPI
functionality work in OpenWebBeans?</h3>
-<p>First off reading about <a href="openwebbeans-impl.html">OpenWebBeans
Core</a> will give you the overall idea.
-Now as mentioned in that description the SPI is simply used to integrate other
+<h2 id="why-using-a-spi-in-openwebbeans">Why using a SPI in OpenWebBeans?</h2>
+<p>First off reading about <a href="openwebbeans-impl.html">OpenWebBeans
Core</a> will give you
+the overall idea about the usage of SPIs in our plugin system. </p>
+<p>Now as mentioned in that description the SPI is simply used to integrate
other
frameworks with OpenWebBeans. The point of gravity for Java EE is definitely
going
towards CDI today and the SPI pattern ensures that OpenWebBeans can manage
this handily.</p>
<p>From a more technical standpoint it's nothing more then a bunch of
interfaces.
@@ -116,6 +117,32 @@ For example a part of the SPI is the fol
<p>After seeing this interface one can easily conclude that frameworks that
want to utilize the Conversation Id functionality must implement this interface.
Now since this is part of the specification for JSF 2.x the JSF plugin of
course implements it and actually the JSF 1.2 plugin as well. Supporting the
Conversation Id in another plugin should be rather intuitive and this is true
for the SPI in general. </p>
+<h3 id="how-does-owb-know-which-implementation-it-should-pick">How does OWB
know which implementation it should pick?</h3>
+<p>Each OpenWebBeans JAR has a property file to configure it's internal
features
+and also the SPI implementation which should be used:</p>
+<div class="codehilite"><pre><span class="n">META</span><span
class="o">-</span><span class="n">INF</span><span class="o">/</span><span
class="n">openwebbeans</span><span class="o">/</span><span
class="n">openwebbeans</span><span class="p">.</span><span
class="k">properties</span>
+</pre></div>
+
+
+<p>All those files contain at single property
<code>configuration.ordinal</code> which defines their
+'importance'. Any setting from a property file with a higher
configuration.ordinal will
+overwrite settings from one with a lower configuration.ordinal. The internally
used
+configuration.ordinal values range from 1 to 100.</p>
+<p>For example: if you use a different UI technology than JSF like Vaadin, you
could still provide
+CDI Conversations by writing an own implementation of the respective SPI and
tweak
+some configuration settings:</p>
+<div class="codehilite"><pre><span class="n">configuration</span><span
class="p">.</span><span class="n">ordinal</span><span class="p">=</span>120
+
+# <span class="n">enable</span> <span class="n">CDI</span> <span
class="n">conversation</span> <span class="n">support</span> <span
class="n">at</span> <span class="n">all</span>
+<span class="n">org</span><span class="p">.</span><span
class="n">apache</span><span class="p">.</span><span
class="n">webbeans</span><span class="p">.</span><span
class="n">application</span><span class="p">.</span><span
class="n">supportsConversation</span><span class="p">=</span><span
class="n">true</span>
+
+# <span class="n">define</span> <span class="n">your</span> <span
class="n">own</span> <span class="n">implementation</span> <span
class="n">of</span> <span class="n">our</span> <span
class="n">ConversationService</span> <span class="n">SPI</span>
+<span class="n">org</span><span class="p">.</span><span
class="n">apache</span><span class="p">.</span><span
class="n">webbeans</span><span class="p">.</span><span
class="n">spi</span><span class="p">.</span><span
class="n">ConversationService</span><span class="p">=</span><span
class="n">some</span><span class="p">.</span><span class="n">mycomp</span><span
class="p">.</span><span class="n">MyVaadinConversationService</span>
+</pre></div>
+
+
+<p>All those tricks allow us to remain extensible in the future and to support
whatever scenario
+we will face.</p>
</div>
<hr>
