cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [osgi] Changing framework?
Date Tue, 28 Jun 2005 10:56:52 GMT
I have got all the test examples from 
o.a.c.test.components.blocks.BlocksManager to run under OSGi except for 
one, testBlockSource4. The failing test case tests the sitemap local 
classloader (one have to remove the map:classpath part of the sitemap in 
the block test1 to make it runnable at all under OSGi).

As there are more convenient ways to handle block local classloading 
than the current sitemap mechanism when one use OSGi, the test case 
failure isn't that much of a problem. But the reason that it fails is a 
problem. The o.a.c.components.classloader.DefaultClassloaderFactory that 
is used requires that the URL to the classes resolves to a 
TransversableSource and OSGi R3 doesn't support that.

OSGi R3 supports a special bundle: protocol for access to bundle content 
through the mechanism and there is also a "URL 
getResource(Strin name)" method for the Bundle interface. But there is 
no support for listing directory content. And after having looked at the 
Knopflerfish sources I haven't found any workarounds either. This means 
that one cannot use e.g. the DirectoryGenerator on bundle content (at 
least in a portable way) in OSGi R3 implementations.

As I found it unlikely that Eclipse could be implemented without 
directory access I took a more detailed look at the Eclipse 
implementation of the OSGi framework. Not suprisingly it contains what 
we need: "Enumeration getEntryPaths(String path)" and "Enumeration 
findEntries(String path, String filePattern, boolean recurse)", in the 
Bundle interface.

Eclipse (IBM) has worked in close coloboration with OSGi and according 
to the Eclipse platform mail list the Eclipse OSGi framework 
implementation use the interfaces from the forthcomming OSGi R4 

A problem with using OSGi R4 is that the only available documentation of 
it is the API documentation from Eclipse. OSGi's development process is 
closed for non members so there are no draft documents that we can use. 
It is supposed to be completely backcompatible for bundle developers so 
alothough irritating, the lack of documentation for OSGi R4 shouldn't 
complicate things that much. IIUC, OSGi R4 will be released soon. And 
both Knopflerfish and Oscar have representants in OSGi and work on R4 

                                 --- o0o ---

AFAICS, we need to change OSGi framework from Knopflerfish to the one 
from Eclipse as the DirectoryGenerator and similar things are necessary 
in Cocoon. I can't say that I'm to happy about it as the documentation 
for the OSGi framework of Eclipse is sparse and unorganized, while the 
Knopflerfish documentation at least is OK. Furthermore the Eclipse OSGi 
framework has been available for standalone use just a few months while 
Knopflerfish has been available for a couple of years. Despite this 
there are of course all reasons to believe that the Eclispe OSGi 
implementation is of high quality as it is the kernel for Eclipse 3.0 
and 3.1 and as IBM has been a member of OSGi since the starting and has 
another products in the area.

                                 --- o0o ---

For testing the Eclipse OSGi framework (,, 
one extract the org.eclipse.osgi_3.1.0.jar from Eclipse 3.1M7 or later 
(the RCP Runtime Binary is the smallest one):

$ java -jar org.eclipse.osgi_3.1.0.jar -console
osgi> help

                                 --- o0o ---

I feel a little bit like geting a Cocoon servlet to run in the current 
OSGi framework before changing, so that we have something that is more 
motivating for others to work at. But then we need to change to the 
Eclipse OSGi framework IMO. Any help would be greatly appriciated.



View raw message