cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <patrickhei...@gmx.de>
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,
> Constants.CLASSPATH_SPRING_CONFIGURATION_LOCATION);
>          }
>          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 
> Constants.CLASSPATH_SPRING_CONFIGURATION_LOCATION:
> 
>      /**
>       * 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
list???
 
> 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] 
> http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-webapp/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/applicationContext.xml?view=markup
> [2] 
> http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/SettingsElementParser.java?view=markup
> [3] 
> http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java?revision=636472&view=markup

I will work through this as soon as possible and will give feedback.
Thank your very much!!
Patrick
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message