cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [osgi] metadata
Date Mon, 04 Jul 2005 16:37:47 GMT
(sorry for a bit lengthy mail)

On Monday 04 July 2005 20:57, Daniel Fagerstrom wrote:
<snip />

Thanks for the clarification.

> Niclas, are you getting up to speed with OSGi? 

Well, I am tugging along with OSGi independently of Cocoon.
As you probably know, I am from the Avalon camp, and has been working on 
running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components are 
exposed as OSGi services as well as ServiceManager.lookup() resolves to OSGi 
services if no 'local implementations' within the Metro container exist.

I am still struggling with some classloading issues. Not sure if it is 
Knopflerfish or the OSGi spec, but the Oscar documentation mentioned that 
OSGi has tightened up the specification around classloading, i.e. less 

> Any thoughts about how to
> use modern component management together with OSGi?

I am no longer sure what "modern component management" would be ;o)
IMHO, Spring's extensive use of XML seems to me to transfer coding from Java 
to XML, and remove the type-safety of Java. They say noone has a problem with 
it, but I think that is hype.
I don't have any experience myself with Pico as such, but use CDI (not 
automatic) a lot myself.

Lately, I have been working with an explicit custom management side. That 
means that each component is free to define its own management requirement, 
and optionally implement it if no existing pattern exists. That means that 
Pico and Spring *could* co-exist, together with a pattern called ContextIOC 
which I find really intriguing (well, I find the "official" pattern a bit 
confusing, but one can boil that down to something with better clarity.)

Another aspect, is that it is possible to push a lot more of the so called 
"component management" over to "Build Time", and end up with "sealed 
components" that are already "resolved and configured". Such "sealed 
component" could end up as a Bundle for deployment, or even just a marshalled 
serialized binary ready to be put into action.

All these are experiments that are being conducted and probably not relevant 
to Cocoon.

Back to OSGi;
The fact that bundles can be loaded, then manipulated (config, permissions, 
++) and finally the entire OSGi platform saved into a deployment bundle is 
also an interesting aspect. 
For Cocoon it should mean that all services that has configuration, should 
implement ManagedService and store all their config state in the 
ServiceRegistration. Which means one can tune the running server and no need 
to worry about that getting lost on restarts.

I am still a long way from understanding all aspects of OSGi. But to me one 
thing is fairly clear; The platform specifications are well balanced, 
allowing for rock-solid implementations in the difficult domain of 
classloading management.

I like it a lot. I like the way I end up developing, hitting reload button 
after a compile. I like to manipulate configs and permissions in runtime. I 
like that only a fraction of the application is reloaded. BUT, it is easy to 
make mistakes keeping references to old instances in other bundles, causing 
all kinds of problems. So great care required! :o)


View raw message