cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [osgi] Component management
Date Mon, 04 Jul 2005 22:10:08 GMT
Was Re: [osgi] metadata

Niclas Hedhman wrote:
> (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.

Interesting indeed! I have thought about something like that for Cocoon. 
I.e. handling all inter block (bundle) component lookup as OSGi 
services. In this way one can use different component containers in 
different blocks. Also such OSGi aware component containers would not 
need to know anything about Cocoon and its interfaces.

We would need to implement an own for ECM++ and other containers that we 
like to support in the short time frame. But when it becomes popular to 
develop applications in Eclipse, RCP, Cocoon 
with real blocks ;) etc, people outside our community will feel need for 
using various Component Managers for intra block/bundle/plugin etc 
component handling and implement such bundles.

The Cocoon core will probably need to depend on ECM++ for some time, but 
the less we make block development depending on any particular 
container, the better IMO.

                        --- o0o ---

Could you tell more about your architecture works? In particular how you 
handle the hot plugability of bundles. Are you using dynamic proxies or 
something like that ?

> 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 
> permissive.
>>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,

How do you handle that, any references?

My view is to choose container at the block level, (the BundleActivator 
could e.g. extend a PicoActivator).

> 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.)

Second time I see a refernence to Context IOC, 
this time when I read the article again, it started to make sense to me 
;) Seems interesting.

> 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.

I'm not certain that the Eclipse OSGi implementation does this.

> 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.

Note to other readers: This means that configurations are handled by a 
certain Configuration admin service that is a standard service from 
OSGi. Both Knopflerfish and Oscar has free implementations, of it.

For the moment I don't know how much we should use standard services: 
log service, configuration admin, URL handler service, http service etc. 
I think we can decide this when we start to understand more about how 
the architecture.

> 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.

I have the same experience this far.

> 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)

Not so cool. Hopefully we can provide infrastructure that help users 
keeping track on the dependencies.


View raw message