cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject OSGi integration (again)
Date Sun, 26 Aug 2007 14:42:12 GMT
As some of you might have seen in the SVN logs, I have started to work 
on making Cocoon work under OSGi again [1].

This will, for the moment, not affect the trunk more than that I might 
refactor or reorganize some stuff based on needs for the OSGi integration.

The main reasons for working on OSGi integration is that OSGi makes it 
possible to push the modularization of Cocoon a bit further.

* Blocks can be dynamically installed, started, stopped and updated 
while the rest of the webapp continue to run. Take a look at Peter 
Kriens demo from last year to see how cool this is [2].

* Each block (bundle) has its own classloader and import and export Java 
packages from other bundles based on OSGi specific info in the In this way the "classloader hell" is handled. Several 
versions of the same jar can be used in the same application.

* Each block has its own Spring context and publish and use services 
(beans) from other blocks based on a special Spring-OSGi configuration [3].

For background on OSGi [4], [5] and [6] might be good. And the 
specification [7] is fairly readable for being a specification.

The work on getting there mainly conisists of: bundelizing the Cocoon 
jars and all needed jars, make beans OSGi services and creating 
infrastucture for building, configuring and running Cocoon in OSGi.


To make a jar working in OSGi it must be converted to a bundle. Which 
means that its must be extended with some OSGi specific, 
info about what packages it exports and imports and some other things. 
Felix contains an excelent Maven plugin that makes this work rather easy 

Also the Felix, Spring-OSGi, Eclipse Equinox and OPS4J has already 
bundelized many popular Java libraries.


The Spring-OSGi project [9] creates OSGi-Spring integration. There is a 
custom name space with constructions for publishing beans as OSGi 
services and for using OSGi services as Spring bean references. The idea 
is that each bundle (block) has its own Sprin application context, and 
that it can publish beans and use beans from other bundles through 
OSGi:s service architecture.

There is a Spring OSGi extender bundle that automatically detects 
bundles with a Spring configurations in the META-INF/spring directory 
and takes care about its services.


Although the Cocoon OSGi integration should work in any OSGi 
implementation I use Felix during development.

I have set up a Maven assembly that creates a directory structure with 
all needed jars and configuration files. So that one just can start the 
Felix OSGi framework with parts of Cocoon inside (see the README [10]).

For logging I use OPS4J Pax Logging [11], which makes all major logging 
frameworks available in an OSGi friendly way.

I use an HTTP service from Eclipse Equinox as the Felix one doesn't 
support Servlet 2.4 only 2.3. An activator [14], [15] has the same role 
as the DispatcherServlet in the ordinary context. But it is dynamic so 
it will detect and use servlet services that comes and goes.

The servlet protocol is available as a "real" Java protocol and is 
available with, using the OSGi URL service.


This far some basic examples that use the servlet service fw works. See 
the README [10] for how to build and test the stuff.

I'll continue with bundelizing the Cocoon core.

There are a number of open problems:
* How to handle configuration
* Spring-OSGi doesn't support prototype scope that well
* How handle the massive "import" of services that is needed for a sitemap?

We had some partial answers to the above question last time we worked on 
Cocoon OSGi integration. Hopefully they can be adapted to the Spring 
OSGi context.

An overview of earlier work can be found in [12] and in my presentation 



View raw message