cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [blocks] Changing component strategy
Date Wed, 25 Jan 2006 21:28:01 GMT
Daniel Fagerstrom wrote:

> So what I want instead is the kind of mechanism that you implemented 
> for the component management in the ECM OSGi services bridge.
> My current view is that the declarative services manager in  OSGi R4, 
> already have good solutions for component handling in a blocks context.
> So I think it would be a waste of time to try to invent something 
> conceptually different for Cocoon blocks. We should IMO keep our 
> architecture as similar to the OSGi ones as possible.
> That will also make it simpler to migrate to OSGi. And we will have a 
> much easier time to reuse work and patterns from Eclipse, Felix and 
> other communities that build on OSGi.

I totally and wholeheartedly agree with what you say.

>> In that scenario, application blocks depend on a block implementing 
>> the "skin" contract, and the implementation chooses the actual skin 
>> block to be used depending on some condition (user, time, host, 
>> whatever). That means we'll have 3 implementations of the "skin" 
>> block interface in the system, and possibly have several different 
>> instances of the e.g. "myCorporateSkin" block with different 
>> configurations (color, stylesheets, etc).
> A skin block is basically a factory, and a wiring is an instruction to 
> ask the factory for a component, give it its deploy time configuration 
> and a unique id and to register the differently configured instances 
> under the different ids in the global service registry. So the above 
> scenario should not be a problem.


> Now, in any case, we can't keep the scheme for component lookup that I 
> have implemented. So we need something different. And if you don't 
> like the OSGi inspired that I would like to go for, we need other 
> suggestions.

If the scenario where we have several implementations of a block 
interface (e.g. skin) and several instances of a given block (e.g. 
CSS-Skin) with different configurations can be handled with a flat 
central registry, then I'm totally fine with it. Go for it!


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message