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. Exactly. -- Grzegorz Kossakowski --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
