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 -->
<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;
}
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.
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 context
just use org.apache.cocoon.spring.configurator.WebAppContextUtils instead of Spring's standard class.
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
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
