Hi all, current work and the thread http://marc.theaimsgroup.com/?t=115493806000005&r=1&w=2 revealed some issues with our current usage of the forrestConfModule.
We use it two times in the forrest-core.xconf with two different names "defaults" and "projects" as prefix. ForrestConfModule does not implement configure(...) meaning it will use the one from super (DefaultsModule). This is adding properties from the configuration (which are different for defaults vs. project). The new org.apache.forrest.plugin.output.inputModule plugin produces properties from an input-module. http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.inputModule/module.defaults.properties shows an example of my setting building the plugins docs. This are exactly the <values> from the defaults xconf configuration. Requesting http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.inputModule/module.project.properties will as well shows exactly the values defined in the xconf. However since we look up a lot more properties via looking up different configuration files the expected behavior would be to return an Iterator based on Enumeration enumeration =filteringProperties.keys(); This can be done by implementing public Iterator getAttributeNames( Configuration modeConf, Map objectModel ). Something like the following: public Iterator getAttributeNames( Configuration modeConf, Map objectModel ) throws ConfigurationException { SortedSet matchset = new TreeSet(); Enumeration enumeration =filteringProperties.keys(); while (enumeration.hasMoreElements()) { String key = (String) enumeration.nextElement(); matchset.add(key); } Iterator iterator = super.getAttributeNames(modeConf,objectModel); while (iterator.hasNext()) matchset.add(iterator.next()); return matchset.iterator(); } The above iterator will return now for module.defaults.properties the properties of the xconf + the ones coming from other properties files. The above iterator will return now for module.project.properties the properties of the xconf + the ones coming from other properties files. http://people.apache.org/~thorsten/whiteboard/conf/ I added there some sample files. New is with the iterator, old using super. Implementing the Iterator will close FOR-800 and reveals the problem I see with the current situation, you can use (right now without any changes applied): <map:transform src="foo.xsl"> <map:parameter name="defaults" value="{defaults:dispatcher.theme}" /> <map:parameter name="project" value="{project:dispatcher.theme}" /> </map:transform> With foo.xsl having: <xsl:param name="defaults"/> <xsl:param name="project"/> <xsl:template match="/"> defaults: <xsl:value-of select="$defaults"/>; project: <xsl:value-of select="$project"/>; </xsl:template> and it returns defaults: pelt; project: pelt; I think it is not good to have two different component-instance that return - for some calls like {defaults/project:dispatcher.theme} the same - for other different {defaults:home} - ~/src/apache/forrest/trunk/ {project:home} - ~/src/apache/forrest/trunk/plugins/org.apache.forrest.plugin.output.inputModule - and for some causing an error {defaults:i18n} - false {project:i18n} - error: Unable to get attribute value for i18n That is way too confusing and error causing for me. If we still need the defaults module then this should be done with a slim downed version of the ForrestConfModule. Actually I tried with <component-instance name="defaults" class="org.apache.cocoon.components.modules.input.DefaultsModule"> but /home/thorsten/src/apache/forrest/trunk/main/webapp/@context.home@/locationmap.xml (No such file or directory) Meaning we "only" have to extend the DefaultsModule with the possibility to resolve @context.home@ etc. ...read on... I am not even sure whether we need the defaults instance at all. We can just use prefixed key aka forrest.home to identify core properties and only use the project instance. We already started to double define variable like {project:forrest.home} = {defaults:home}, so I think it is best to merge both modules and support only {project:forrest.home} or maybe renamed like {properties:forrest.home} I think we should merge the modules ASAP. wdyt? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
