cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: application-context loading order
Date Sun, 16 Mar 2008 14:39:00 GMT
Patrick Heiden pisze:
> Good Morning!

Hi Patrick.

> I am still interested in understanding that appCtx-mechanisms. I've read through several
APIs and
> several source files. After this first quick breed I could not find specific class(es),
wich is
> responsible for load up block-specific contexts and the whole webAppCtx respectively.
Where is
> the place to dig through?

I'm not surprised that you are confused becuase the whole issue is not that easy to figure
out, really.

Let me explain everything is managed.
First of all, root webAppCtx is initialized by Spring of course. Then it reads the 
applicationContext.xml[1] file created by webapp archetype.
There you can find following line:

   <!-- Activate Cocoon Spring Configurator -->

It's crucial for understanding how loading of Spring beans works.

The SettingsElementParser[2] class is responsible for handling that element. Among other interesting

stuff, it contains following method:

     protected List getBeanIncludes(Element settingsElement) {
         final List includes = super.getBeanIncludes(settingsElement);
         final boolean readFromClasspath = Boolean.valueOf(this.getAttributeValue(settingsElement,

READ_FROM_CLASSPATH_ATTR, "true")).booleanValue();
         if ( readFromClasspath ) {
             includes.add(0, Constants.CLASSPATH_SPRING_CONFIGURATION_LOCATION);
         return includes;

It returns list of beans to be parsed in addition to one can be found in applicationContext.xml.

Actually, our design is to not put anything in applicationContext.xml file but to suitable
Spring config file and use this bean-includes mechanism. Let's see the value of 

      * The location of spring configuration files in the classpath.
      * From this location bean definitions (*.xml) and property overrides (*.properties)
      * are read.

Oh, interesting, isn't it? The asterisk here means "read xml file that can be found in 
META-INF/cocoon/spring file of whatever JAR-file you can find in the classpath". That means,
it will 
include *all* beans declarations from *all* blocks.

Now, if you recall that we come from applicationContext.xml file you realize that all block-specific

beans declarations go into one, global Webapp application context created using standard mechanisms

of Spring. That's what I meant when I was saying that there is only one global bean container
and no 
real isolation.

You may now wonder what about sitemap-specific child containers. I don't want to go into details

because I consider this functionality as legacy and not worth long explanations. However,
if you 
really want to know the details I could share my knowledge.
For now I would say that, if you want to stay on the safe side and always get correct webapp
just use org.apache.cocoon.spring.configurator.WebAppContextUtils instead of Spring's standard

The last detail that should be mentioned is ServletFactoryBean[3] class from SSF. It creates
contexts but it isn't (yet) used for anything so I don't think it should get much attention
right now.

I hope this helps you a little bit.


Grzegorz Kossakowski

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

View raw message