Carsten Ziegeler wrote:
With the help from Leszek we now have a Cocoon version in trunk which
which was rather small and of questionable quality, thanks for the
credit tough :)
does not need any deployment plugin. This means you can just drop the
jar files into WEB-INF/lib and are done! So it doesn't matter if you're
using Maven, Ant or some other strange tool :)
All you need is the main Spring applicationContext.xml with our two
elements for setting up Cocoon and the Avalon bridge.
So, what has changed?
We now load all configuration files directly from within the jar files,
so all files in META-INF/cocoon/avalon, META-INF/cocoon/spring and
META-INF/cocoon/properties are applied at runtime without the need to
extract these files.
do we need to load configuration files from WEB-INF/cocoon/*? After all
if one wants to have configuration unpack it may be done using
WEB-INF/classes/META-INF/cocoon/*. Same result. No duplication.
CocoonPropertyOverrideConfigurer could be then simplified. We could drop
scanClassPath and just provide a 'location' attribute which is
classpath*:/META-INF/properties for core and ./config/properties for
blocks.
So we could remove:
CocoonPropertyOverrideConfigurer.java:110-115
if ( this.scanClassPath ) {
ResourceUtils.readProperties("classpath*:META-INF/cocoon/spring",
mergedProps, this.resourceLoader,
this.logger);
ResourceUtils.readProperties("classpath*:META-INF/cocoon/spring/" +
mode, mergedProps,
this.resourceLoader, this.logger);
}
SettingsElementParser.java:78-82
try {
this.handleBeanInclude(parserContext, null,
Constants.DEFAULT_SPRING_BLOCK_CONFIGURATION_LOCATION, "*.xml", true);
} catch (Exception e) {
throw new BeanDefinitionStoreException("Unable to read spring
configurations from " + Constants.DEFAULT_SPRING_BLOCK_CONFIGURATION_LOCATION, e);
}
SettingsBeanFactoryPostProcessor.java:188-196 (2 includes instead of 4)
// now read all properties from the properties directory
ResourceUtils.readProperties("classpath*:META-INF/cocoon/properties",
properties, this.getResourceLoader(), this.logger);
// read all properties from the mode dependent directory
ResourceUtils.readProperties("classpath*:META-INF/cocoon/properties/" +
mode, properties, this.getResourceLoader(), this.logger);
// now read all properties from the properties directory
ResourceUtils.readProperties("/WEB-INF/cocoon/properties", properties,
this.getResourceLoader(), this.logger);
// read all properties from the mode dependent directory
ResourceUtils.readProperties("/WEB-INF/cocoon/properties/" + mode,
properties, this.getResourceLoader(), this.logger);
Currently on startup of Cocoon, all COB-INF directories are extracted to
{webapp-directory}/blocks/{block-name}.
What is missing?
1. With the changes from above, Cocoon does not run as an unexpanded war
file anymore. So I think we should extract the COB-INF directory into
the temporary directory and mount the blocks from there. This should be
very simple to change.
apart from one thing, how do I do that?:
<map:match pattern="mobile/**">
<map:mount uri-prefix="mobile" src="blocks/geminismart-server-mobile/"/>
</map:match>
<map:match pattern="central/**">
<map:mount uri-prefix="central" src="blocks/geminismart-server-central/"/>
</map:match>
<map:match pattern="**">
<map:mount uri-prefix="" src="blocks/mobilebox-webapp-commons/"/>
</map:match>
when I get block files unpacked to some temporary directory which
location can change any time.
2. We should check on startup if we need to extract a COB-INF directory
again. If anyone has a good idea how to check this without too much work
would be great.
wouldn't it be sufficient if we checked for blocks/block-name directory
existence?
3. Update to our deployer plugins (and perhaps archetypes) - we changed
some directory names and obviously the deployment has changed. So we
should check if all our plugins, development procedures, archetypes etc.
are still working. I just tested the core-webapp.
Next few hours I will be trying to get all my 2.2 projects up and
running again.
Once we have solved these three issues we should release a RC-1 asap.
+1
--
Leszek Gawron CTO at MobileBox Ltd.
