cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: getComponent vs. context.getAttribute
Date Wed, 12 Mar 2008 10:35:45 GMT
Carsten Ziegeler wrote:
> Patrick Heiden wrote:
>> Thanks for this one! It might even be the simpler approach. What is
>> confusing for me so far (informations I got from Grzegorz
>> Kossakowski), that the actual implementation (2.2) does not 'really'
>> support different bean-containers. I am able to define beans within
>> blocks A context (META-INF/cocoon/spring/*.xml) and they are visible
>> to other blocks of my webapp as well. How does the future look like
>> for this and how should actual design/configuration of beans (e.g. a
>> service-layer) be done to be prepared?
> There are different approaches; one of them is the new block concept
> (which Grzegorz is refering to) and that does not support a hierarchy
> of containers - but I'm not an expert for blocks, so I have no idea
> what has been done/will be planned for that.

Yep, I haven't mentioned these sitemap-specific containers because they
are only there for back-compatibility and they are very likely to be
deprecated in the future. Moreover, these sitemap-specific containers
support only Avalon components and not Spring beans.

As for now I advise to put beans configurations into
META-INF/cocoon/spring/*.xml and declare dependencies between blocks
that reflect dependencies between beans. This should be enough for any
future invention that will guarantee true isolation between blocks.
> The other approach is the 2.1.x compatible approach: by creating a
> hierarchy of sitemaps (using map:mount) you create a hierarchy of
> containers (like it was in 2.1.x). It is possible to define beans on
> er per sitemap base. However, it seems that current development of
> Cocoon favours the blocks concept.

Grzegorz Kossakowski

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message