commit | db41a5e5b9b3da19212aa481f931c23a6edcabad | [log] [tgz] |
---|---|---|
author | Raymond Auge <raymond.auge@liferay.com> | Sun Apr 07 12:29:35 2019 -0400 |
committer | Raymond Auge <raymond.auge@liferay.com> | Sun Apr 07 21:42:57 2019 -0400 |
tree | f0078d947be76f56ed02ce2196ffbccc1e04ae3c | |
parent | 6fada3fadccfc1e24e8652581ed3430b3c8f225b [diff] |
[CDI] some documentation Signed-off-by: Raymond Auge <raymond.auge@liferay.com>
This is an implementation of OSGi CDI Integration Specification (hereafter referred to simply as OSGi CDI).
The build uses maven so it should look pretty familiar to most developers.
mvn clean install
The main artifact is the CDI Component Runtime (CCR) implementation. a.k.a. the extender bundle:
<dependency> <groupId>org.apache.aries.cdi</groupId> <artifactId>org.apache.aries.cdi.extender</artifactId> <version>${aries-cdi.version}</version> <scope>runtime</scope> </dependency>
However all the required dependencies are available using the Aries CDI BOM:
<dependency> <groupId>org.apache.aries.cdi</groupId> <artifactId>org.apache.aries.cdi.bom</artifactId> <version>${aries-cdi.version}</version> <type>pom</type> <scope>import</scope> </dependency>
TODO
This repository provides an example for how to assemble an executable jar providing a complete runtime for you to just drop in your CDI bundles. It comes complete with logging, Gogo shell, Config Admin, Http Whiteboard support, and OSGi Promises.
Once you've completed a successfull build, you should be able to execute the command:
java -jar cdi-executable/target/executable.jar
and be presented with a gogo shell prompt ready for you to install a CDI bundle.
The goal of OSGi CDI was to remain as true to both technologies as possible. This proved possible due to the extensive feature set provided by each technology.
The main actors in the OSGi CDI architecture are:
CDI bundle - bundles which contain CDI beans and opted-in to OSGi CDI (best achieved with supporting build tooling.)
CDI container - an instance of the CDI machinery hosting all beans inside a bundle and managing their instantiation.
CDI Component Runtime (CCR) - is what Aries CDI implements using the extender pattern. It awaits CDI bundles creating a private CDI container for each one.
OSGi CDI Components (hereafter referred to simple as components) - A set of closely related CDI beans having a common OSGi lifecycle. A CDI bundle has 1 to N components. Again, all beans within the same component have a common OSGi lifecycle within the CDI bundle. The collective dependencies declared by all bean making up a component are treated as a single set. As such any single unsatisfied dependency of the component will prevent the entire component from activating, or upon removal, will cause the component to deactivate.
OSGi CDI Portable Extension (hereafter referred to simply as portable extensions) - bundles which contain portable extensions and opted-in to providing those extensions in a OSGi CDI compatible way.
Service Registry - The OSGi service registry is the central actor by which all inter bundle service activity is managed. As such, CDI bundles interact with other bundles via the service registry as well.
The nice thing is you can mix and match through the lingua franca of services. A bundle that is internally implemented with DS can talk to a bundle that is internally implemented with CDI (or Blueprint, etc...) Neil Bartlett - Twitter
Configuration Admin - OSGi CDI is well integrated with Configuration Admin the way that Declarative Services (DS) is. As such, all components in CDI bundles are configurable via configuration admin.
When a CDI bundle is identified by CCR several steps are taken before any bean is instantiated:
javax.enterprise.inject.spi.Extension
services must be located. The bundle's CDI container will remain inactive until all portable extension services are located. Conversely, for a bundle with an active CDI container, if an identified extension goes away the CDI container is torn down.ApplicationScoped
, Dependent
, RequestScoped
, SessionScoped
, ConversationScoped
, any custom scopes, etc.; all of these make up the container component.org.osgi.service.cdi.annotations.ComponentScoped
are part of the container component.@SingleComponent
are roots of a single component.@ComponentScoped
are also part of this single component.@FactoryComponent
are roots of a factory component.@ComponentScoped
are also part of this factory component.javax.enterprise.inject.spi.BeanManager
of the CDI container is published as a service with the service property osgi.cdi.container.id
. (always, even if the container component is empty.)ServiceFactory
like DS component services)ServiceFactory
). Service instances are created whenever the getService
method of the factory is called, and destroyed when the ungetService
is called. Note: The service registry is the one tracking if a bundle has already gotten factory service instances.PrototypeServiceFactory
). Service instances are created whenever the getService
method of the factory is called, and destroyed when the ungetService
is called.@Initialized(ComponentScoped.class)
@BeforeDestroy(ComponentScoped.class)
@Destroyed(ComponentScoped.class)
ServiceFactory
like DS component services)ServiceFactory
). Service instances are created whenever the getService
method of the factory is called, and destroyed when the ungetService
is called. Note: The service registry is the one tracking if a bundle has already gotten factory service instances.PrototypeServiceFactory
). Service instances are created whenever the getService
method of the factory is called, and destroyed when the ungetService
is called.@Initialized(ComponentScoped.class)
@BeforeDestroy(ComponentScoped.class)
@Destroyed(ComponentScoped.class)
Time to move onto the examples.