Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote: ...
I strongly suggest that we start with org.apache.cocoon.* to avoid these problems down the road (including, yes, gump problems)
Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from Avalon interfaces to Cocoon
interfaces which are more or less the same but just use a different
package. In that case these components run in Cocoon but not in any
other container anymore that provides Avalon compatibility. And
that's imho bad. Not every project uses Cocoon, so it's absolutely preferable to have components that I can use in several projects.
Ok, I think if we decide to use our own versions of the interfaces it will still be possible to do some hacky things and still provide compatilibity with the Avalon versions.
So what do others think?
Cocoon components will never work putside of Cocoon. Non-cocoon components should not use the Cocoon interfaces.
I don't see the problem, as long as we don't mix all like we did with Avalon.
IMO, the answer isn't so simple. A lot of people chose to use Avalon interfaces to implement component-based systems, especially for components related to business logic. These components can run inside Cocoon, but not only. And this choice was made possible because the COP-related interfaces are defined by outside of Cocoon, i.e. they aren't tied to the web tier in a more global architecture.
Now what if COP-related interfaces are defined within Cocoon? People are left alone to write their business-related components. This is a giant step back.
Also, I think the block kernel and ECM serve different complementary purposes. The kernel is useful to implement coarse-grained entities (blocks) that can be hotdeployed and hotswapped. ECM is useful to implement fine-grained entities (components) that need to be configured, eventually pooled, etc. But ECM-managed components aren't individually hotswappable (they don't need to).
So we can consider that there actually exists two levels of containement. Blocks are managed by the kernel, and components are managed by an ECM-type container, which, being part of a block is itself managed by the kernel.
This approach has the benefit of being an evolutionary path of what we have today and still allows people to benefit from COP interfaces to implement their own components, be them integrated into Cocoon or not.
WDYT?
On paper, yes, but in real life it's not so simple.
Avalon/ECM cannot define hotswappable components. This means that if your block has ECM components they cannot be exposed to other blocks, otherwise they would create "hard wires" between the two components that will not allow the blocks to be hotswappable.
So, like we already said before, it is *totally* possible to have a block load avalon components thru an avalon sandbox (sort of a avalon->cocoon adapter). This allows you to reuse your avalon stuff "AS IS". But this also means that your block cannot expose those components outside of that block.
Are there reasons that prevent me from writting a 'block wrapper' which can be exposed?
This *is* already planned and allows you to keep your existing stuff, but there is no way you can have the avalon interfaces cooperate with the existing cocoon kernel functionality because of the intrinsic nature of an hotswappale mechanism.
-- Reinhard
