cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Initial version of spring-app block
Date Fri, 18 Mar 2005 16:41:42 GMT
Reinhard Poetz wrote:
> Was defining a spring application context on a per sitemap base a design 
> decision or the easiest way to write a prototype? Shouldn't it be the goal that 
> each block (and of course Cocoon core) can provide beans via some export 
> functionality and this exported beans can be reused by any other block depending 
> on this block? Or for now, wouldn't we want to use Spring managed beans all over 
> in our Cocoon application?
> (Sorry for the maybe dumb questions - don't want to criticize your work in any 
> way :-) )
:) No problem - we discussed this briefly last week in [1]. In short,
it's design decision. We identified - for now! - the sitemap as the
central configuration place for an application (or a block): classpath,
xconfs and now "application support" through own Spring application
contexts. (The concept is open to other containers as well, you could
also use Hivemind or whatever here).
Now, using a global Spring app context is of course an alternative. But
with the context on a per sitemap base, you can have different
applications running inside Cocoon with different Spring configurations.
And they are shielded through the new classloading concept. In addition
- though not implemented yet - you can simply create a hierarchy of
spring app contexts by creating a hierarchy of sitemaps.

So with this feature, you can either use the "usual spring way" by using
the spring servlet (filter), or you can defined a spring context at the
main sitemap and the spring beans will be accessible throughout the
whole Cocoon application. But this feature is targetted for running
different applications/blocks inside Cocoon with different
Spring/container configurations.

As soon as our blocks have an export mechanism for avalon components
through a service manager, the spring beans will be exportable without
any extra work as they are now reachable through a service manager.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message