Wicket and OSGi

After playing around with the OSGi JPA and JTA components of Apache Aries for a while, it was only natural to try and add a web layer to my sample projects. The Aries samples all use plain old servlets and JSPs, so I wondered if Wicket would work in this context.

So far, I had only ever used Wicket in standard Java EE web applications, but I had noticed the Wicket JARs come with an OSGi manifest, so someone must have tried to use Wicket in OSGi before.


Then I noticed the ominous

DynamicImport-Package: *

manifest header, which is not the best way of interacting with client code, and what's worse, Wicket does not even import its own static dependencies like org.slf4j, but relies on the catch-all dynamic import.

A discussion on the Wicket Users mailing list confirmed my suspicion that this had to be related to Wicket's page deserialization requiring to load classes from user bundles.

Anyway, I had a feeling it shouldn't be too hard to make this work without dynamic imports. In addition, it would be nice to inject OSGi services into Wicket components, just like CDI or Spring beans.

So I started coding, and by now, there is a first proof-of-concept sample using Wicket on top of Aries, Jetty, OpenJPA, Derby and Equinox. The sample code is included in my OSGi Enterprise sandbox project at Google Code. More details can be found in the OSGi Enterprise wiki.

Update 10 Jul 2011: After some polishing, my Wicket/OSGi glue code has made it into the Wicketstuff project - see the OSGi Integration wiki page for more details. This subproject targets the Wicket 1.5 release and will automatically be integrated with the next release or release candidate of Wicketstuff.

Snapshot artifacts are currently available from the Sonatype OSS repository.

The first shot in the OSGi Enterprise project works with Wicket 1.4.x.

wicket-osgi from Wicketstuff cannot be used with Wicket 1.4.x.