felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@apache.org
Subject svn commit: r1741128 - /felix/site/trunk/content/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext
Date Wed, 27 Apr 2016 00:20:00 GMT
Author: cziegeler
Date: Wed Apr 27 00:20:00 2016
New Revision: 1741128

URL: http://svn.apache.org/viewvc?rev=1741128&view=rev
Update SCR example


Modified: felix/site/trunk/content/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext?rev=1741128&r1=1741127&r2=1741128&view=diff
--- felix/site/trunk/content/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext
+++ felix/site/trunk/content/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext
Wed Apr 27 00:20:00 2016
@@ -7,7 +7,7 @@ The purpose of this example is to re-imp
 The spell checker service of Example 6 was complex because it needed to aggregate all available
dictionary services and monitor their dynamic availability. In addition, the spell checker
service's own availability was dependent upon the availability of dictionary services; in
other words, the spell checker service had a dynamic, one-to-many dependency on dictionary
services. As it turns out, service dependencies are not managed at all by the OSGi framework
and end up being the responsibility of the application developer. Declarative Services tries
to eliminate complex and error-prone service dependency handling by automating it. To do this,
Declarative Services parses XML files in a bundle that describes the components we want to
create and their service dependencies. Instead of writing a lot of complex code, we simply
use annotations. At build time the tooling creates a declarative XML file which is included
in the bundle. There is no need to write an Activator.
-The above meta-data tells the generic activator to create one instance of `tutorial.example8.SpellCheckerImpl`,
which we will define next. The meta-data also tells the generic activator that the instance
has an aggregate service dependency (in this case, one-to-many) on dictionary services and
that the services should be tracked dynamically. It also specifies the bind and unbind methods
that should be called on the instance when dictionary services appear and disappear. It is
important to understand that the generic activator is constantly trying to maintain the instances
defined in the meta-data file. At any given point in time, a specific instance may be valid
(if all service dependencies are satisfied) or invalid (if any service dependencies are unsatisfied),
but at all times the generic activator is trying to get the declared instances into a valid
state. The code for our new spell checker service is very similar to the implementation in
Example 6, but it is no longer implemente
 d as an inner class of the activator. We define the new spell checker service in a file called
`SpellCheckerImpl.java` as follows:
+We define the new spell checker service in a file called `SpellCheckerImpl.java` as follows:

View raw message