Author: marrs
Date: Wed Mar 4 18:52:20 2015
New Revision: 1664113
URL: http://svn.apache.org/r1664113
Log:
Small changes to the shell tutorial.
Modified:
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/getting-started.mdtext
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/leveraging-the-shell.mdtext
Modified:
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/getting-started.mdtext
URL:
http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/getting-started.mdtext?rev=1664113&r1=1664112&r2=1664113&view=diff
==============================================================================
---
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/getting-started.mdtext
(original)
+++
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/getting-started.mdtext
Wed Mar 4 18:52:20 2015
@@ -11,9 +11,11 @@ When using the dependency manager, your
The following paragraphs will show various examples that explain how to do
this. Subsequently, some more advanced scenarios will be covered that involve
listening to dependency and component state changes and interacting with the
OSGi framework from within your component implementation.
+To use the dependency manager, you should put the
`org.apache.felix.dependencymanager.jar` in your classpath while compiling and
in your OSGi framework when running.
+
### Registering a service
-The first example is about registering a service. We extend
`DependencyActivatorBase` and in the init method we use the reference to the
`DependencyManager` to create and add a component. For this component we
subsequently set its service interface and implementation. In this case the
interface is the `Store` interface, the second parameter, null, allows you to
provide properties along with the service registration. For the implementation,
we only mention the `Class` of the implementation, which means the dependency
manager will lazily instantiate it. In this case, there is not much point in
doing that because the component has no dependencies, but if it had, the
instantiation would only happen when those dependencies were resolved.
+The first example is about registering a service. We extend
`DependencyActivatorBase` and in the `init` method we use the reference to the
`DependencyManager` to create and add a component. For this component we
subsequently set its service interface and implementation. In this case the
interface is the `Store` interface, the second parameter, `null`, allows you to
provide properties along with the service registration. For the implementation,
we only mention the `Class` of the implementation, which means the dependency
manager will lazily instantiate it. In this case, there is not much point in
doing that because the component has no dependencies, but if it had, the
instantiation would only happen when those dependencies were resolved.
Notice that the dependency manager API uses method chaining to create a more
or less "fluent" API that, with proper indentation, is very easy to read.
@@ -25,8 +27,6 @@ Notice that the dependency manager API u
.setImplementation(MemoryStore.class)
);
}
-
- public void destroy(BundleContext context, DependencyManager manager)
throws Exception {}
}
@@ -74,8 +74,6 @@ Our second example is that of a componen
)
);
}
-
- public void destroy(BundleContext context, DependencyManager manager)
throws Exception {}
}
@@ -113,8 +111,6 @@ Sometimes, simply injecting services doe
)
);
}
-
- public void destroy(BundleContext context, DependencyManager manager)
throws Exception {}
}
@@ -167,8 +163,6 @@ Not all dependencies are on services. Th
)
);
}
-
- public void destroy(BundleContext context, DependencyManager manager)
throws Exception {}
}
Modified:
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/leveraging-the-shell.mdtext
URL:
http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/leveraging-the-shell.mdtext?rev=1664113&r1=1664112&r2=1664113&view=diff
==============================================================================
---
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/leveraging-the-shell.mdtext
(original)
+++
felix/site/trunk/content/documentation/subprojects/apache-felix-dependency-manager-4/tutorials/leveraging-the-shell.mdtext
Wed Mar 4 18:52:20 2015
@@ -15,11 +15,18 @@ Typing help ```help dm``` in the gogo sh
stats, stat, st Displays components statistics
wtf Detects where are the root failures
options:
- bundleIds, bid, bi, b <List of bundle ids or bundle symbolic
names to display (comma separated)> [optional]
- componentIds, cid, ci <List of component identifiers to display
(comma separated)> [optional]
- components, c <Regex(s) used to filter on component
implementation class names (comma separated), can be negated using "!" prefix>
[optional]
- services, s <OSGi filter used to filter some service properties>
[optional]
- top <Max number of top components to display (0=all)> This
command displays components callbacks (init/start) times> [optional]
+ bundleIds, bid, bi, b <List of bundle ids or bundle symbolic
+ names to display (comma separated)> [optional]
+ componentIds, cid, ci <List of component identifiers to display
+ (comma separated)> [optional]
+ components, c <Regex(s) used to filter on component
+ implementation class names (comma separated), can be
+ negated using "!" prefix> [optional]
+ services, s <OSGi filter used to filter some service
+ properties> [optional]
+ top <Max number of top components to display (0=all)> This
+ command displays components callbacks (init/start)
+ times> [optional]
parameters:
CommandSession
@@ -30,7 +37,7 @@ __List all dependency manager components
```dm```
-Sample output
+Sample output:
[9] dm.demo
[6] dm.demo.Probe(type=radiation) unregistered
@@ -70,23 +77,23 @@ __Find all components for a given classn
```dm c .*ProbeImpl```
-dm c or components finds all components for which the classname of the
implementation matches the regular expression.
+`dm c` or `components` finds all components for which the classname of the
implementation matches the regular expression.
__Find all services matching a service filter__
```dm s "(type=temperature)"```
-dm s allows finding components based on the service properties of their
registered services in the service registry using a standard OSGi service
filter.
+`dm s` allows finding components based on the service properties of their
registered services in the service registry using a standard OSGi service
filter.
__Find out why components are not registered__
```dm wtf```
-Sample output
+Sample output:
2 missing dependencies found.
-----------------------------
The following service(s) are missing:
* dm.demo.Sensor is not found in the service registry
-wtf gives the root cause for components not being registered and therefore
their services not being available. In a typical application components have
dependencies on services implemented by components that have dependencies on
services etcetera. This transitivity means that an entire chain of components
could be unregistered due to a (few) root dependencies not being satisified.
wtf is about discovering those dependencies.
\ No newline at end of file
+`wtf` gives the root cause for components not being registered and therefore
their services not being available. In a typical application components have
dependencies on services implemented by components that have dependencies on
services etcetera. This transitivity means that an entire chain of components
could be unregistered due to a (few) root dependencies not being satisfied.
`wtf` is about discovering those dependencies.
\ No newline at end of file
