> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
