cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 15:45:12 GMT
Leo Sutic wrote:

> 
>>From: Stefano Mazzocchi [mailto:stefano@apache.org] 
>>
>>Because avalon components are directly wired while the new components 
>>will be loosely wired. This is the only way we can achieve 
>>hot-swapping polimorphism and Avalon4 simply cannot do that.
> 
> 
> So, even if you instead of having:
> 
>   Client ---- Component
> 
> have:
> 
>   Client ---- Proxy ---- Component
> 
> You can't do the hotswap?

We are doing this, yes.

But there are a few tricky things here: cocoon blocks are polymorphic 
*themselves*, polymorphism is not exposed only thru the java interfaces, 
but it's a higher level concept (for example, you have a "skin" block, 
then you have your own skin flavor, think of debian virtual packages)

If you are dealing with resources (as debian is, for example), this is 
no big deal, and it's all taken care at resource lookup.

Cocoon Blocks are special because they contain *both* services (thru 
components) and resources (thru pipeline invocations).

Please note how polymorphism is used not only for different flavors (as 
for a skin, for example), but also (and way more important!!) for 
versioning!

If block A1 requires block B implemented right now by Block B1, then 
block A looks up a component that is currently on B1, but we hotswap the 
wiring to B2 (the new version), block A should not notice a difference.

But...

> Is this related to the statefulness of the component?

... as you correctly spot, the thing is way more tricky than it looks at 
first.

The way we solved this was to enable a sort of loose-coupling wiring 
between components. This requires block A to check for the wire validity 
everytime a service is invoqued and, if not, look it up again (obviously 
the framework will provide helping code for this).

Avalon's notion of wiring is way more primitive than this and it is 
impossible for us to obtain the functionality we want without doing 
back-incompatible changes to the avalon framework.

-- 
Stefano.


Mime
View raw message