cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [2.2] Runtime deployment
Date Sat, 04 Nov 2006 10:29:25 GMT
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.


Mime
View raw message