> My goal was to leave the cocoon webapp servlet alone so it > didn't need to be edited when deploying on any servlet container.
Same here. I wanted to be able to deploy cocoon as an application which supported your sitemap based cocoon application - developing in the recommended way they get packaged up together. > As you found, both Jetty and Tomcat have the concept of a context.xml file. > On tomcat, (the documentation says) this file can be used to define > properties > or environment variables. But I found that these expressions do not get > passed to Spring placeholders: I don't think you can specify an environment variable for a single context - I think it's set for the entire servlet container (I could be wrong). This ruled out the environment variable approach for me because I wanted to be able to run multiple instances mounted under different locations on the servlet container. i.e. http://host/app1 -> cocoonapplication1, http://host/app2 -> cocoonapplication2. I came across the context configuration method in Solr and it seems like the right way to do it. I *think* the cocoon spring configurator uses the PropertyPlaceholderConfigurer[1] which doesn't look the servlet context because it's not necessarily being run in a servlet. For that you're meant to use the ServletContextPropertyPlaceholderConfigurer[2] but as I said when I tried to create one of them in the application context, hoping that through the magic of spring it would pick up the servlet context initialisation parameters, the whole thing stopped working. 1 - http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html 2 - http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/web/context/support/ServletContextPropertyPlaceholderConfigurer.html I'm new to Spring, Maven and log4j and I never really understood Avalon so it's been quite hard on my brain this far... > I'd like to see your 'trivial' bean that copies values from the context. > But do you think the fact that the context Environment elements are > ignored is a bug in the way tomcat starts up Spring? tl/por/pub/ccpp/CocoonContextPropertyProvider.java -- package tl.por.pub.ccpp; import java.util.Properties; import java.util.Enumeration; import javax.servlet.ServletContext; import org.springframework.web.context.ServletContextAware; import org.apache.cocoon.configuration.PropertyProvider; import org.apache.cocoon.configuration.Settings; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; public class ServletContextPropertyProvider implements ServletContextAware, PropertyProvider { ServletContext ctx; private Log log = LogFactory.getLog(ServletContextPropertyProvider.class); public void setServletContext(ServletContext ctx) { this.ctx = ctx; log.debug("CCPP context set"); } public Properties getProperties(Settings sets, String runmode, String path) { Properties props = new Properties(); Enumeration initParameters = ctx.getInitParameterNames(); while (initParameters.hasMoreElements()) { String name = (String)initParameters.nextElement(); props.setProperty(name, ctx.getInitParameter(name)); if (log.isDebugEnabled()) { log.debug("CCPP initParam: "+name+"="+ctx.getInitParameter(name)); } } log.debug("CCPP properties gotten"); return props; } } -- Then you add a bean to your applicationContext.xml file <!-- Provide initialisation from servlet context --> <bean name="org.apache.cocoon.configuration.PropertyProvider" class="tl.por.pub.ccpp.ServletContextPropertyProvider"/> The @name is important, I got that wrong the first time :-) -- Stephen Rosman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
