Bundle.update: OSGi in Java EE, JSR 294 Marked Inactive

Posted by Alex Blewitt on Dec 11, 2009

Sections

Development

Topics

JCP Standards ,

Java

Tags

Java SE ,

Java EE ,

SpringSource dm Server ,

Jigsaw ,

JDK 7 ,

Maven ,

OSGi ,

Glassfish ,

Websphere ,

Tycho ,

IntelliJ IDEA ,

JSR 291 ,

JSR 294 ,

Conferences ,

JSR 277

Since the last bundle.update, a number of interesting events have occurred in the OSGi and modular Java space. JSR 294 has been marked inactive, the Enterprise Expert Group has released draft 4, WebSphere will allow direct running of OSGi applications and upcoming OSGi conferences have early bird discounts and call for speakers finishing soon.

The inactivation of JSR 294

Both of the Sun-led JSRs on modularity (JSR 294, Improved Modularity Support in the Java programming language, and JSR 277, Java Module System) are now in an inactive state. This makes the only JCP approved modularity system JSR 291, which although based on the slightly older OSGi 4.1, is actively being used in a wide number of different systems, including Sun's recently-released GlassFish v3 application server.

It's unclear why JSR 294 was demoted to inactive status recently (JSR 277 having been inactive for a year). The last message to the group suggested that:

• In addition to implementing JSRs, JDK7 will also have implementation-specific features, such as a) the classpath (never part of any JSR) and b) the Jigsaw module system.
• JDK modularization uses the Jigsaw module system. Module visibility is controlled by a prototypical module-info.java file; that may change. Module-private accessibility is actually not used in the modularization, partly to assist with bootstrapping.
• Further discussion of any aspect of Jigsaw belongs on the Jigsaw-dev list.

There hasn't been any progress since the simple module system was proposed; and although it has been implied that version semantics are governed by JSR 294, that clearly isn't the case, since development is occurring on the jigsaw-dev mailing list outside the JSR 294 expert mailing group. Even the above suggests that Jigsaw is an implementation-specific feature to modularise the JDK, which although a laudable goal in itself, is not going to result in write-once, run anywhere modules. This may not be relevant in the future in any case; JDK 7 isn't likely to be released until 2011 at the earliest, and appservers have already bet on OSGi.

Update: Since this piece was posted, Alex Buckley has confirmed that the inactivation was an automatic process owing to the age of the original proposal, rather than the winding down of the project. A new review has been promised by the end of the year.

WebSphere, GlassFish, DM Server OSGi based servers

Kirk Knoernschild posted about the enterprise getting its OSGi; the recent announcement of WebSphere V7 alpha allows OSGi bundles to be deployed into WebSphere (although the WebSphere server has been running on an OSGi kernel since 2006).

This week's release of GlassFish v3 also brings an OSGi runtime to the Sun enterprise Java server. Although GlassFish doesn't yet support native running OSGi bundles directly, since it can be hosted in both Equinox and Felix, it's possible to run other bundles concurrently with a running GlassFish server.

SpringSource's dm Server 2.0.0.M6 already provides support for running OSGi web bundles and with its bundle repository, is showing the way forward for enterprise runtimes.

Maven 3 and Tycho builds, repository and marketplace

As Maven 3 draws closer, with its Tycho build for OSGi based applications, it is being used to build both EGit and Tigerstripe at Eclipse.

There has been some debate around the queryability of Maven repositories versus P2 repositories, but in fact Maven repositories can be queried too. Arguably, Maven's repository is one of the most successful aspects of the whole Maven build process, enabling artefacts to be downloaded based on dependency requirements automatically. P2 may be more advanced in terms of Pack200 compression and ability to update non-JAR components; but Maven's über repository easily outclasses Eclipse's P2's repository in breadth. Furthermore, the P2 repositories are often fragmented into multiple separate repositories, whereas there is a single Maven global repository which all projects share.

Recently, the Eclipse foundation announced the Eclipse Marketplace, which grew from the successful Eclipse Plug-In Central site. EPIC was originally set up as a means to provide a central location for the downloads of popular plug-ins that weren't hosted on the main Eclipse.org site, such as Findbugs and Checkstyle.

The Eclipse foundation bought the rights to EPIC back in 2006, but then largely left it unchanged until the recent development of the Eclipse marketplace. During that time, a lack of centralised downloading structure and the pain of the Update Site -> P2 switchover hurt the proposed features and benefits of a central site for finding and downloading plugins.

In addition to the plug-ins, the new marketplace also hosts markets for (commercial as well as free) RCP applications and training and consulting providers.

Lastly, IntelliJ 9 has been released; and both the community edition and commercial edition have support for building OSGi applications. With both the top Java IDEs being able to build OSGi applications natively, and headless build support being available for OSGi applications, developing modular Java applications has never been easier.

OSGi 4.2 EEG draft available

The OSGi Enterprise Expert Group has released early draft 4. The purpose of the EEG is to define a specification to allow JEE style applications to be natively hosted as bundles in an OSGi runtime.

• Web apps can now be installed as bundles. Not only does this allow an OSGi runtime to host WARs (in the same way as a server like Jetty), but the WAR can also have versioned dependencies in the runtime. This has previously been possible with Pax Web, but this brings a standard so that any OSGi runtime can be used.
• JMX control of bundles in an OSGi framework, as well as standardised bindings to core OSGi services such as Package Admin, Cofniguration Admin and so on.
• Transactions are provided as part of a JTA binding, which allows transactions to be acquired from an OSGi service.
• JNDI access from and between OSGi services.
• JDBC factory which is OSGi compatible (unlike Class.forName()).

These services will allow enterprise applications to run inside an OSGi environment instead of needing a whole JEE stack. Although JEE 6 has been released, it's likely to be one of the last JSRs that gets approved, since Mark Reinhold commented in a closures Q&A:

Q Why not start a closures JSR now and let its Expert Group do the work of formulating a new proposal?

A For the same reason that there’s not yet a JSR for Project Coin, namely that no new Java SE JSR is likely to be approved until the present dispute in the JCP Executive Committee is resolved.

Upcoming OSGi conferences

London hosts OSGi DevCon London on the 23rd February 2010, in conjunction with JAX London. The conference program has been decided, with Kirk Knoernschild giving the keynote. Early bird registration is open until Thursday 17th December.

Santa Clara hosts the OSGi DevCon on 22nd-25th March 2010, in conjunction with EclipseCon 2010. Robert "Uncle Bob" Martin provides the keynote; early registration ends at the end of December. The call for speakers is still open; if you'd be interested in giving an OSGi talk, then submit a proposal.

1. Back to top

   OW2 JOnAS is missing in the OSGi app server section

   by Guillaume Sauthier

   The OW2 JOnAS 5.x serie has been using OSGi for 2 years now: internally using bundles, services even components with Apache Felix iPOJO but also supporting natively the deployment of user's bundles.
   
   It's also offering a Java EE to OSGi bridge for traditional Java EE applications to access OSGi services (and benefits of OSGi dynamism). Revert is also possible and it's one of the unique feature (AFAIK) provided by JOnAS and its EJB 3 container: the publication of EJB3 business interfaces as OSGi services, allowing OSGi code to benefits of the Java EE well known programming model (and transaction, persistence, management, ...)
   
   For more information, check out the 5.1 documentation.

   Reply

• Older >