Blueprint or CDI

Model archetype is using blueprint (even if the xml file is generated at compile time via annotation scanning) while Business and route archetypes are using CDI (pax-CDI): Why? Note that the both framework can NOT reference other beans produced by the other framework within the same bundle (e.g. you can’t reference a cdi bean in blueprint and vice versa).

Blueprint

Blueprint is the most known and stable bean wiring OSGI framework. It’s purpose is to wire beans together with the help of an xml descriptor located in src/main/resources/OSGI-INF/blueprint/[file].xml For example, if you want to inject a validator on one service like this: 
1
2
3

public class HelloServiceJaxRS implements net.osgiliath.hello.business.impl.HelloServiceJaxRS {
	@Setter
	private HelloObjectRepository helloObjectRepository;...
You will have a counterpart in the xml file: 
1
2
3
4

    <bean id="helloServiceJaxRs"
		class="net.osgiliath.hello.business.impl.services.impl.HelloServiceJaxRS">
		<property name="helloObjectRepository" ref="helloObjectRepository"></property>
	</bean>
With blueprint, you can also reference properties (compendium), some custom namespaces (for example aries-jpa, aries-tx) or OSGI service.

Traps

All external classes referenced in a bp.xml file are not scanned by the bundle plugin so they’re package-import are not added to the MANIFEST of your bundle, you’ll have to add them manually in the osgi.bnd file

CDI

CDI wires beans via annotations on classes, fields… As the code is concise and do not repeat (no need for xml), it can add burden on your java classes, making them less readable. In order to enable a certain kind of annotations for your bundles, you’ve to add a Require-Capability header on your osgi.bnd file 
1
2
3
4
5
6
7

Require-Capability: osgi.extender;filter:="(osgi.extender=pax.cdi)",\ <!-- Declaration to enable CDI on your project (you'll also need a bean.xml file)-->
 org.ops4j.pax.cdi.extension;filter:="(extension=pax-cdi-extension)",\ <!-- allow export and reference OSGI services with annotations -->
 org.ops4j.pax.cdi.extension;filter:="(extension=validation)",\ <!-- Enables JSR 303 (validation) annotations scanning -->
 org.ops4j.pax.cdi.extension;filter:="(extension=cxf-integration-cdi)",\ <!-- Enables REST services declarations via annotations -->
 org.ops4j.pax.cdi.extension;filter:="(extension=deltaspike-core-api)",\ <!-- DS is a nice angular stone for CDI -->
 org.ops4j.pax.cdi.extension;filter:="(extension=camel-cdi-extension)",\ <!-- JMS annotations scanning -->
 org.ops4j.pax.cdi.extension;filter:="(extension=eager)" <!-- Enables Eager beans annotations, they'll start when bundle state will be 'Active' -->
In addition, you must have at least a beans.xml file located on src/main/resources/META-INF: this file can also refer to alternatives beans (for example while testing), or interceptors (something that wraps your methods adding some behaviour to it).

Traps

  • Config admin properties that are referenced via annotations are not updated while changing, also you can tell from which persistent id the property come from: beware to not publish the same property twice.
  • @Consume camel annotation cannot be used with CDI, you have to make a route to handle messages (extends routebuilder).
  • @ContextName camel annotation can only reference a ‘general’ camel context, you can’t have many for a platform
  • Model archetype cannot be CDI-driven as (for the time writing) only aries-jpa can handle persistence.

Comments