reading settings in cocoon.xconf
Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: reading settings in cocoon.xconf
Leszek Gawron wrote: Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. Do we really need this? :) Currently the implementation is imho clean and separating concerns: there is one component reading the properties and providing them via Spring and another one is able to read avalon configurations. I don't want to mix these as some day in the future we will remove the Avalon stuff (or make it optional) and then we have to change everything again. Can we somehow configure this in a different way? Perhaps by passing in a system property pointing to the properties directory? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Leszek Gawron wrote: Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. Do we really need this? :) Currently the implementation is imho clean and separating concerns: there is one component reading the properties and providing them via Spring and another one is able to read avalon configurations. I don't want to mix these as some day in the future we will remove the Avalon stuff (or make it optional) and then we have to change everything again. Can we somehow configure this in a different way? Perhaps by passing in a system property pointing to the properties directory? As long as it is configured automatically so the only thing that user does is: mvn clean compile cocoon:deploy jetty:run -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: reading settings in cocoon.xconf
Leszek Gawron wrote As long as it is configured automatically so the only thing that user does is: mvn clean compile cocoon:deploy jetty:run I'm not that familiar with all aspects of the cocoon:deploy plugin, but I thought that this one is deploying all files into the necessary locations? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote:
Leszek Gawron wrote
As long as it is configured automatically so the only thing that user
does is:
mvn clean compile cocoon:deploy jetty:run
I'm not that familiar with all aspects of the cocoon:deploy plugin, but
I thought that this one is deploying all files into the necessary locations?
Not exactly. This is only one mode of operation when you work on
cocoon-webapp archetype.
If you invoke it for any project that is not war packaged then it is
assumed you are locally developing your cocoon block. Your main
sitemap.xmap, cocoon.xconf, web.xml and bunch of other core files get
generated:
--- sitemap.xmap ---
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:classloader factory-role=org.apache.cocoon.classloader.ClassLoaderFactory/reloading
class-dir
src=file:/c:/dev/projects/donnelley/donnelley-admin/target/classes//
/map:classloader
/map:components
map:pipelines
map:pipeline
map:match pattern=
map:redirect-to uri=blocks/donnelley-admin//
/map:match
!-- resources of block jars --
map:match pattern=_cocoon/resources/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
!-- mount all development blocks --
map:match pattern=blocks/donnelley-block-common/**
map:mount uri-prefix=blocks/donnelley-block-common
src=file:/c:/dev/projects/donnelley/donnelley-admin/../donnelley-block-common/src/main/resources/COB-INF//
/map:match
map:match pattern=blocks/donnelley-admin/**
map:mount uri-prefix=blocks/donnelley-admin
src=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/COB-INF//
/map:match
!-- mount all deployed blocks --
map:match pattern=*/**
map:mount src={1}/ uri-prefix={1}/
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
features: - local classes loaded via reloading classloader
- COB-INF sources mounted directly from src/ directory
- COB-INF from other modules (if specified) also mounted from
source
--- web.xml ---
generated from scratch, all cocoon blocks contribute patches from
META-INF/xpatch/*.xweb
cocoon.xconf:
cocoon version=2.2
!--+
| Include the core roles definitions. This is for the sake of clarity,
| as they are implicitely loaded at startup, but we may want to remove
| this implicit behaviour in the future now that we have the include
| mechanism.
+--
include src=resource://org/apache/cocoon/cocoon.roles/
!--+
| Include all configuration files ending with .xconf
| from the xconf directory.
+--
include dir=context://WEB-INF/cocoon/xconf pattern=*.xconf/
!--+
| Include all configuration files ending with .xmap
| from the sitemap-additions directory.
+--
include dir=context://WEB-INF/cocoon/sitemap-additions pattern=*.xmap/
!--+
| Include Spring beans definition files ending with .xml from
| the spring directory.
+--
include-beans dir=context://WEB-INF/cocoon/spring pattern=*.xml/
include-beans
dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/spring/
pattern=*.xml/
include dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/legacy/xconf/ pattern=*.xconf/
include dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/legacy/sitemap-additions/ pattern=*.xmap/
/cocoon
features:
- local spring contexts, avalon context and sitemap additions mounted
directly from source directory
The main goal is to provide everything from source folder.
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts (covered by include in cocoon.xconf)
- spring contexts (covered by include in cocoon.xconf)
- sitemap additions (covered by include in cocoon.xconf)
- properties
- those in src/main/resources/COB-INF/config/properties/ covered by
automatic loading in block sitemap
- those in src/main/resources/META-INF/properties are NOT COVERED
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: reading settings in cocoon.xconf
Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote:
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts (covered by include in cocoon.xconf)
- spring contexts (covered by include in cocoon.xconf)
- sitemap additions (covered by include in cocoon.xconf)
- properties
- those in src/main/resources/COB-INF/config/properties/ covered by
automatic loading in block sitemap
- those in src/main/resources/META-INF/properties are NOT COVERED
Thanks for the nice overview, Leszek - I've never used it this way.
To be honest, I have no good idea how to solve this. But I think putting
these include into the xconf is not the right way :(
Your proposal to use a system property would work. But its ugly. You
would need to have this configured in every pom.xml:
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty6-plugin/artifactId
version6.0.0beta10/version
configuration
connectors
connector
implementation=org.mortbay.jetty.nio.SelectChannelConnector
port/port
maxIdleTime3/maxIdleTime
/connector
/connectors
webAppSourceDirectorytarget/${artifactId}-${version}/webAppSourceDirectory
contextPath//contextPath
systemProperties
systemProperty
nameorg.apache.cocoon.mode/name
valuedev/value
/systemProperty
systemProperty
nameorg.apache.cocoon.additional.property.directory/name
value/src/main/resources/META-INF/properties/value
/systemProperty
/systemProperties
/configuration
/plugin
It should not be something that needs configuring in pom.xml. This
configuration issue should go directly somewhere into /target/cocoon-webapp
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Would it help, if you could specify the properties dir in the settings element in the applicationContext.xml? Currently cocoon:settings/ is used; we could simply extend it with support for an addition dir attribute. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Carsten Ziegeler wrote: Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Would it help, if you could specify the properties dir in the settings element in the applicationContext.xml? Currently cocoon:settings/ is used; we could simply extend it with support for an addition dir attribute. Hmmm ... not really. And the system property solution would not also work. Everything because you may mount more that one development block directly from source: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration useShieldingClassloaderfalse/useShieldingClassloader useShieldingRepositoryfalse/useShieldingRepository blocks developmentBlock groupIdcom.mobilebox.donnelley/groupId artifactIddonnelley-block-common/artifactId localPath../donnelley-block-common/localPath /developmentBlock /blocks /configuration /plugin which needs to read properties from: - src/main/resources/META-INF/properties - ../donnelley-block-common/src/main/resources/META-INF/properties -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: reading settings in cocoon.xconf
Leszek Gawron wrote: Hmmm ... not really. And the system property solution would not also work. Everything because you may mount more that one development block directly from source: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration useShieldingClassloaderfalse/useShieldingClassloader useShieldingRepositoryfalse/useShieldingRepository blocks developmentBlock groupIdcom.mobilebox.donnelley/groupId artifactIddonnelley-block-common/artifactId localPath../donnelley-block-common/localPath /developmentBlock /blocks /configuration /plugin which needs to read properties from: - src/main/resources/META-INF/properties - ../donnelley-block-common/src/main/resources/META-INF/properties We could allow more than one directory in the system property or the attribute (separated by comma). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
