Enterprise Expert Group

I am currently sitting in the Kempinski hotel on the Munich airport waiting for my flight home. Very tired but even more satisfied. In the last few weeks we have been struggling in the Enterprise Expert Group about core issues. The last meeting, 8 weeks ago in Dublin, was actually quite heated and a bit depressive, but this meeting turned out highly productive!

The key issue was the focus of the work we're doing in the JEE APIs. Is the focus to make JEE applications run on OSGi unchanged or do we provide a recommended way of using those APIs on OSGi? The problem is that JEE has many built-in assumptions that do not hold in an OSGi world. JEE containers have a application-thread association, a much simpler class loading model with most dependencies contained in the application, and there is no visible life cycle. Especially the creation of providers through static factories is very cumbersome in OSGi.

A good example to highlight these problems is for example the static nature of JNDI. An application performs a new InitialContext() call and expects that a proper context is returned. The environment can influence the returned context via singleton that can only be set once.

The proposal on the table is that an OSGi bundle sets this singleton and then, when called, would get a Context service from the service registry. The real proposal is a bit more complicated, but this is the principle. At first sight, this sound like a viable solution. It allows bundles deliver new Context providers, and it is compatible with normal JSE/JEE code that uses new InitialContext().

Unfortunately, this static factory pattern ignores the dynamic life cycle of bundles. It raises the following concerns:

• Ordering - When the application does new InitialContext(), is the singleton already set? Is the desired provider already registered?
• Ownership - On whom's behalf is the Context provider service checked out? It is notoriously hard to determine the caller's bundle context from the stack, if at all possible in a reliable way.
• Staleness - What happens when the Context provider is stopped? The InitialContext then has a reference to a stale object.

These solutions are solvable if one lowers the bar that we held so far. You can order bundles with start-level ordering and in most cases the stale reference will not crash the system.

The problem we now faced in the last weeks was that many, coming from the JEE world, felt that the portability aspect was more important than the issues raised by this solution. Others felt that though lowering the bar in a product might be acceptable, an OSGi specification should show the right way to do it in OSGi. They felt that expecting that a JSE/JEE application always needed some porting to make it work on OSGi. There seems to be no free lunch for modularity.

During this meeting it was clear that we reached a consensus. The design was changed to be service based. In principle, a bundle would set the singleton and then register a service, allowing bundles to properly synchronized with this singleton. It is then up to containers to implement the correct life cycle handling for OSGi challenged applications. Additionally, the spec will recommend not to use the JEE/JSE static factories but will contain a section that outlines the consequences when they are used, given a proper warning to the deployer.

It was kind of invigorating to see how we have been able to come to a consensus even though the debate was sometimes heated and messy. If we can continue in this spirit, then I think we will see some very interesting specifications coming out of this group in the coming years.

Peter Kriens