From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
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.
smime.p7s
Description: S/MIME Cryptographic Signature
