cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Real blocks - current state and next steps
Date Wed, 07 Sep 2005 22:47:13 GMT
Joerg Heinicke wrote:

> I just wanted to have answers, not new code :) But thanks very much 
> for it.
> Are other things coming as fast as this time when I just ask for them? 
> What about real blocks? ;)

Although there is a lot of work before we have converted everything to 
real blocks and put all the infrastructure in place, we are fairly close 
to get working "real blocks".

We allready have some of the main parts: the packaging and classloader 
isolation is done with OSGi and we have a working Cocoon (with some 
restrictions) in terms of OSGi bundles (see for references). I implemented the 
sitemap part,, 
of it before knowing anything about OSGi. And Sylvain have implemented 
component handling for blocks, but it is not 
integrated yet. The main remaining work is to integrate these parts.

I just give an overview, we can discuss all the details while devloping 


I only care for the servlet case now to not complicate things to much. 
We can refactor to take care of other environments when we have 
something that works.

The Blocks servlet

The main block is the blocks servlet bundle. It create the Cocoon Core 
object (o.a.c.core.Core) and make it available to all other blocks as a 
(OSGi) service (I committed o.a.c.core.osgi.OSGiBootstrapEnvironment 
yesterday that can beused for creating a Core adapted to the OSGi 
context). It also makes all components in the Cocoon core (src/java/**) 
available as services. The blocks servlet does not necesarily contain 
the core it might be an own library bundle that the blocks servlet just 
depend on.

The blocks servlet bundle creats a servlet and register it in a (OSGi) 
HttpService. The servlet dooes nothing in it self it just works as a 
switch board for the blocks. When a block with sitemap functionality is 
deployed in the OSGi container, it will register a Block service and the 
service migth also be deployed at a certain mount point in the URI 
space. The blocks servlet bundle will react (through OSGi event 
handling) on the presence of a new sitemap block and redirect all http 
calls to the blocks mount point to its Block service.

The blocks servlet bundle will contain part of the code from 
o.a.c.components.blocks.BlocksManager. The main difference from the 
BlocksManager is that the blocks servlet bundle will not be responsible 
for deploy time configuration and creation of the individual blocks.

A Block

An individual block will use some common BlockActivator as activator. 
The BlockActivator will base its work on the block.xml file of the 
block. If block.xml contains a reference to an .xconf file it will 
create a parent service manager that contains all the components of the 
.xconf file and exports the components as services so that other blocks 
can use them. Furthermore it will translate all requests for components 
that not is part of the local container to (OSGi) service requests so 
that the component can be delivered from other blocks. Sylvain have 
allready written most of the code for the component management and it 
can befound in o.a.c.core.osgi.

The block.xml will be used for configure an 
o.a.c.components.blocks.BlockManager. If there is a sitemap reference i 
block.xml a Block service will be created and exposed. And if there is a 
local component manager as described above, it will be used as parent 
component manager for the sitemap.

One question is how to give deploy time configuration (the wiring.xml) 
about mount point, block attributes, and connections to other blocks, to 
a block. Maybe the block specific properties that Carsten is working on 
could be used. At a later stage the configuration manager service of 
OSGi could be useful.

After having implemented what is described above we have a first version 
of real blocks. There are however some surrounding components and infra 
stucture we need to make it really usefull.


Library bundles

Today all the jars that the core depend on is uncluded in the Cocoon 
core bundle. It would be much more practical to package them as separate 
bundles. There is a tool, Mangen, that take a set of jars, 
amalyze all interdependencies and generate the appropriate manifest 
files with exports and imports. It is also configurable in various ways. 
Using this tool would simplify the manifest creation a lot.

It wouuld be practical if the communities for the various jars supported 
OSGi manifest files. We could probably do that within the Excalibur 
project and maybe also in Jakarta commons.

Build system

Currently we have some rather ad hoc tasks for building the bundles. 
There is an ongoing OSGi Maven2 plugin project within Apache Felix (the 
Apache OSGi incubator project). It would be good if we could take part 
in that project so that the plugin works for us.

Block repository

The repository situation is not that clear to me. There is an Oscar 
Bundle Repository (OBR) that has good 
support for OSGi bundles. It handles dependencies among other things. 
Eclipse also have bundle aware repository. OTH our build system is 
connected to a M2 repository. Maybe we could work within Felix to make 
it possible to use the OBR functionality on M2 repositories?


During development it is easiest to deploy block by using an (possibly 
graphical) OSGi console. Is this ok for production systems, should we 
have some web gui?


We are currently using the Knopflerfish OSGi framework, wich implements 
release 3 of OSGi. It works well, but the licence isn't ASF compatible 
(to week) and some functionality that we need is lacking (ability to 
list directory content in bundles, and more advanced version handling). 
OSGi R4 has a compatible licence and the features that we miss from R3. 
Either we can use the OSGi R4 framework from Eclipse, it is stable and 
rather complete, but not as easy to use. Or we can use the OSGi R4 
framework from Felix that is under development, but it is Apache and 
easier to influence.


View raw message