cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <>
Subject Re: application-context loading order
Date Sun, 16 Mar 2008 15:39:16 GMT
> Hi Patrick.

Hello Grzegorz! 

> 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 -->
>    <configurator:settings/>
> 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,
>          }
>          return includes;
>      }

Ah, there it is 'hiding' ;)

> 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 block 
> 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.
>       */
>      public static final String CLASSPATH_SPRING_CONFIGURATION_LOCATION =
>                  "classpath*:META-INF/cocoon/spring";
> 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.

So far so good! Really interesting...

> 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.

Well, isolation issue-handling could be interesting in some spots, but I really think, that
these cases are rare and in 'old-spring-fashion' responsible to preserve (blocks-)beans-usage-errors
(e.g. within flowscripts). <-- this is of course POV from app-architect/developer ;)
> 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.

I really enjoy your comprehensive answers and if I am right by guessing that these sitemap-specific
containers are in 'avalon-scope' then I am not going to use them. If I am wrong, I'll be back,
relying on your knowledge ;)

> For now I would say that, if you want to stay on the safe side and always
> get correct webapp context 
> just use org.apache.cocoon.spring.configurator.WebAppContextUtils instead
> of Spring's standard class.

Could you please be a bit more specific? I`m not sure what you are trying to tell me. Do you
just mean, that I should use that if I want to get ROOT_WEB_APP_CTX? Or am I able to get specific
child-contexts out of that (e.g. with RequestAttributes ?) ? >>a bit confused<<
Besides: As long as the cocoon.getComponent("FOOBAR")-method will work and true isolation
of contexts is not supported, I see no case for asking cocoon to spit out specific contexts.
My concerns only go towards the order of context-loading. And this point is still confusing
due to Joergs reply within this thread. He said, that appctx-loading-order is aplphabetical
- how could this be, if my RCL-output after mvn jetty:run shows up with an alphabetic unordered
> The last detail that should be mentioned is ServletFactoryBean[3] class
> from SSF. It creates child 
> 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.
> [1] 
> [2] 
> [3] 

I will work through this as soon as possible and will give feedback.
Thank your very much!!
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen:

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

View raw message