Getting Started for CDI Users

Modularity in Java EE

The module concept of Java EE 6 is rather coarse: A web application is a single module, typically a fairly large one, with a single CDI container. You cannot easily share components between applications, except by embedding them into each WEB-INF/lib or by moving them to a shared location of the application server, making them visible to all applications deployed on the server.

CDI injection cannot cross module boundaries. The only way to indirectly inject shared resources or EJBs from other modules is by wrapping them in a local producer method.

The set of managed beans is determined during application deployment and remains fixed during the lifetime of the applications.

Modularity in OSGi

OSGi has a very rich and dynamic module concept. OSGi applications typically contain dozens or hundreds of fairly small modules or bundles, some of which may come and go during the lifetime of the application. Bundles can register services in the central OSGi service registry, or look up and use services registered by other bundles, without having to know exactly the bundle providing a given service. Like bundles, services may come and go at any time.

The Best of Both

The idea of Pax CDI is to break up a monolithic application with a large CDI container into a number of smaller bean bundles, each with its own CDI container. CDI containers from different bundles can interact indirectly through the OSGi service registry.

A bean from bundle A may inject a (proxy of a) bean provided by bundle B, if B has published the bean in the OSGi service registry.

Pax CDI encapsulates OSGi APIs in a portable CDI extension, enabling application developers to publish or consume OSGi services by a handful of annotations.