OSGi and JEE – CDI

May 22, 2015September 13, 2015 arievanwi

It doesn’t happen often that I discover something in software engineering that feels like finding your missing link at the exact time you need it. I had it when I discovered OO programming back in the 1980’s, found the standard packages that came with Java in the 1990’s and discovering Dependency Injection (DI) as a way to glue parts together with the Spring framework in the 2000’s.

Since then, DI has evolved a lot: I became to dislike Spring because of all the features and magic that were added over time, which not only binds your application to it but also disqualifies it for OSGi environments. As a result, I ended up using OSGi Declarative Services as the lightweight solution for DI, which was often enough for most OSGi based applications with or without web front-end.

A couple of months ago, for a project I was involved in, JSF was chosen as the front-end technology. This decision was not taken lightly and the application is indeed perfectly suited for JSF. However, the rest of organisation kind of demanded an OSGi based back-end which left us to bridge the gap between JSF and OSGi services. After considering various JEE/OSGi combinations (Wildfly, Glassfish, Karaf), it was decided to use a plain OSGi framework combined with CDI as the bridge between JSF and the OSGi services. CDI on OSGi is however not standardised in the OSGi enterprise specification and therefore support is limited.

A (the only?) project that tries to bring CDI to OSGi is OPS4J’s PAX-CDI. At first glance the project appeared to be promising, but in the end we did not use it. The reason for this is that it was complex to set it up, mainly because it has a lot of dependencies outside the standard APIs and it is poorly documented. In the end I just didn’t get it to work properly in combination with JSF. Furthermore, it misses some of the features we had as requirement, like injection of lists of services and the option to export bean managers via the OSGi service registry (so beans can be used by multiple JSF web bundles).

Writing the glue between OSGi and CDI ourself didn’t seem that difficult: the CDI standard provides a standard means to extend the functionality of the CDI container. Such extensions allow you to link in your own functionality at specific phases during the construction of the container. And indeed this proved to be a very elegant way of extending the CDI container to our needs. Unfortunately, bootstrapping the container is not standardized (yet), so for bootstrapping the container still some implementation specific calls and adapters were needed. But in the end we created a bundle that only depends on the Weld OSGi bundle (and its dependencies).

In the coming blogs I will explain in more detail about the requirements, set-up and design of this bundle. For those who can’t wait, you can have a look at it now on github.

OSGi and JEE – Entity and transaction managers

March 28, 2015September 13, 2015 arievanwi

Entity manager

In the previous post, the creation of EntityManagerFactory OSGi services from a persistence declaration file was discussed. An entity manager factory is however not the interface normally used in application programming. For that EntityManager instances are used.

An entity manager is the interface to perform persistence activities like retrieving and storing objects from the database. The OSGi enterprise specification does not mention it in the JPA chapter and that leaves a gap between the specification and the application programmer.

Looking at how an entity manager is used in JEE containers, which is via a @PersistenceContext annotated injection point, it is obvious to provide an OSGi entity manager service to application programmers so it can be injected into other beans via declarative services or service tracking. There are however two specific problems with this:

According to the JEE specification, entity managers should only be used by one thread for the duration of a request. This cannot be guaranteed for normal OSGi services.
In JEE, entity managers are managed by the container and closed at the end of a request. There is no such thing in OSGi.

The solution provided by the OSGi JEE extender project for issue 1. is to return a proxy for the entity manager OSGi service. This proxy will maintain an entity manager per thread and delegate the calls made through the proxy to that thread specific entity manager, see figure:

This however still leaves issue 2. which is impossible to solve without an usage pattern. This pattern is via a JTA TransactionManager.

Transaction manager

The Java transaction API defines an interface for both application programmers as persistence implementers to cope with transactions. Application programmers normally use the UserTransaction interface while persistence implementers use the Transaction and TransactionManager APIs. In practice the user transaction is a simplified façade to the transaction manager API.

In the persistence implementation for the OSGi JEE extender project both are needed since interaction takes place with application programmers and persistence back-ends.

As such both a TransactionManager service as well as a UserTransaction service is provided by the JPA extender. The entity manager handling registers the constructed entity managers with the transaction manager to make sure that the constructed entity managers take part in the transaction and are closed on transaction end. From an application programmer point of view, transactions need to be started somewhere and ended elsewhere. This functionality is provided via an <codeUserTransaction OSGi service that is mainly an adapter to the transaction manager and transaction interfaces.

OSGi and JEE – JPA

March 10, 2015June 20, 2018 arievanwi

JEE perspective

As an application programmer, using JPA in a JEE container is as simple as injecting an EntityManager in your bean. In the back a lot of actions are performed by the JEE container:

It takes care of creating EntityManagerFactory instances for the persistence units that are defined in the persistence.xml files. This is done with help of PersistenceUnitProvider implementations which are found via the Java service provider solution.
It takes care of the thread-safety of the EntityManager instances that are injected into the beans. This because, by specification, an EntityManager instance cannot be shared by multiple threads.
It takes care of transaction management.

JPA and OSGi

For OSGi, JPA interacton is specified in chapter 127 of the OSGi enterprise specification. To state it short: a persistence unit globally results in an EntityManagerFactory for the unit to become available as service in the OSGi service registry. Application programmers can look-up those services in the service registry, create EntityManagers from them and use those to perform persistence actions and dispose them afterwards.

There are however some complications:

The persistence.xml file may contain JNDI look-ups for the data sources to use. For JNDI a different chapter is present in the OSGi specification (chapter 126, implemented by an Aries project), but to state it simple: the way JNDI bootstrapping was designed is not compatible with the dynamic nature of OSGi. If I have time, I will create a different blog to explain this, but for now my statement is to forget JNDI in combination with OSGi. The alternative however means declaring the database properties in every persistence unit present, which isn’t clean either.
As indicated earlier, the application programmer can create an EntityManager instance, but is left with persistence unit local transactions. Although global transactions are described in chapter 123 of the OSGi enterprise specification, there is still a gap between the specification and day-to-day use.

JPA solutions for OSGi

There are a couple of solutions that allow JPA on OSGi via an implementation of the JPA chapter from the OSGi specification:

Gemini JPA is the eclipse implementation. It uses eclipselink as JPA provider and extends it to register an entity manager factory in the OSGi service registry.
Aries JPA is the implementation of the Apache Aries project. It uses OpenJPA as JPA provider.
The JPA part of the OSGi enroute project. Can use eclipselink and hibernate as persistence provider.

All of these solutions have their peculiarities:

Aries JPA seems to work only with a JPA 2.0 version (which disqualified it for me).
Aries JPA and Gemini JPA make use of JNDI for lookups of the data sources.
Gemini JPA uses (unnecessary?) wiring magic which makes it prone for starting order issues.
The JPA part of the enroute project does not allow for different data sources for different persistent units. Furthermore, it only allows JTA persistence units and requires an XA data source. It does however extend the JPA solution with EntityManager services that can be directly used via service look-ups.

Container perspective on JPA

As already indicated earlier, from a JEE container perspective, the main interface to JPA is delivered by the javax.persistence.spi.PersistenceProvider interface. This interface has actually two views for creating an javax.persistence.EntityManagerFactory:

A Standard Edition view, for standalone creation of an entity manager factory. This method just passes the name of the persistence unit and leaves it up to the provider to do the rest
A container view, for creation of entity manager factories in managed mode. This method needs a complete definition of a persistence unit, passed as an interface to the provider.

In OSGi, the second variant is the appropriate one to use: there is no way that the persistence provider is able to construct the persistence unit just by name.

The persistence unit definition, represented by an implementation of the javax.persistence.spi.PersistenceUnitInfo interface, is globally a mapping that conforms to the contents of a persistence.xml file (like data sources, mapping files, classes, etc.) with some additional methods to interact with the container. The latter methods are rather obscure, at least in an OSGi environment:

addTransformer() should add a class transformer that performs some kind of byte code weaving, meaning: adapt the classes when they are loaded. Although in OSGi something alike is present since recent version (probably as a result of the enterprise specification), I don’t like the practice at all. Especially, if you consider that persistence units may be re-loaded for example if the bundle is stopped and started, but the bundle classes remain loaded in the mean time.
getNewTempClassLoader() should return a class loader that can be used to temporary load classes that are not visible to the application and only used during creation of the entity manager factory. Sorry, but I don’t like this at all either: by definition class loaders have a delegation model, so why would one want this? My expectation is that this has to do with the byte code weaving of addTransformer(), but I am not sure.

In my opinion, the use of persistence providers that need the last two methods for normal operation should be reconsidered.

Chapter 127?

This all makes actually a (half-hearted) implementation of the OSGi enterprise chapter 127 relatively simple:

Make sure that the PersistenceProvider interface from a JPA implementation is exported via the OSGi service registry.
Track PersistenceProvider services and bundles containing the chapter 127 persistence header.
Parse the persistence definition files from the bundles and use them to create a EntityManagerFactory via the PersistenceProvider interface.
Register the factory with the service registry.

But that of course does not include transaction handling nor EntityManager injection.

And JNDI?

Earlier in this blog I indicated that I don’t like JNDI in OSGi. So, what about the data sources that are specified in the persistence definition files? These are according to the specification JNDI look-ups. For that the OSGi JNDI namespace indication as specified in the OSGi enterprise specification JNDI chapter can still be used. It is however not delegated to an OSGi JNDI implementation, but parsed by the JPA bundle itself (which is actually very simple to do). Therefore, just use the osgi:service/javax.sql.DataSource syntax to reference a data source that is available via a look-up in the OSGi registry.

OSGi and JEE (again)

March 7, 2015September 13, 2015 arievanwi

I have always had mixed feelings when using JEE. When I started with JEE around 2000, I never took the standards seriously because of the overhead involved and the superiority of the alternatives that were available. As such, I always used some other framework on a servlet engine. First with own implementations to handle functional separation between user interface and business logic, later using Spring as Dependency Injection framework.

After I discovered OSGi around 2008, I continued the approach using Spring-DM. Spring development however has moved away from OSGi since then in such a way that I either kept using old versions of Spring with Spring-DM or dropped using it completely in favour of plain OSGi Service Component annotations.

In the mean time, I always felt kind of sad that I was not able to use real JEE standards. Especially since the standard developed: with JEE5 and JEE6 the specifications became more modular and added features we needed so badly for our day-to-day software development. But always one step too late for the projects I did. Furthermore, I like OSGi because of its modularity and dynamics which are needed for the environments I do projects in. The base of the JEE standards however remains large monolithic applications which require relatively large downtimes for re-deployments.

And that’s where we are now: we can either use JEE7 standards with one of the implementing containers, or use OSGi. I know that some containers (like JBoss or Glassfish) allow the use of OSGi features on the container, but their focus is on delivering a JEE compliant container, not OSGi. For example: Glassfish itself uses (and runs in) an OSGi container. However, its installation is over 300(!) bundles (without any application), massive from OSGi perspective.

Is all lost for lightweight JEE7 based OSGi?

No. Although the hype for using OSGi in enterprise environments may be gone, it has caused some advantages for the OSGi centred mind:

In 2008 third party libraries were almost never OSGi aware. Nowadays libraries come often as OSGi bundles or are delivered as such via the Glassfish variants on maven central.
The JEE7 standard is more modular than before, built on interfaces and the use (from container perspective) of the reference implementations are documented relatively well. This because the reference implementations are used in multiple products. Furthermore, they are all open-source, making it easier to analyse the behaviour in case of doubt.
There is some standardization around the JEE standards for OSGi via the OSGi enterprise specification.
There are integration projects, like Apache Karaf, that make an effort to bring all open source solutions for JEE to OSGi.

A couple of weeks ago, a discussion arose about the environment to use for a new project I am involved in. The project developers wanted to go for JEE7 via JBoss Wildfly, but the maintenance organization required lightweight OSGi. I suggested to investigate a solution that allowed the usage of some of the JEE7 standards (in this case JPA/JTA, JSF and CDI) on plain OSGi.

And that’s what I will report about in the coming period.