Day: February 23, 2009

I’ve been looking quite extensively at the cocoon-spring-configurator, trying to work out how to make it fit into our preferred java webapp config scheme: context-params.

By default, cocoon-spring-configurator just reads Properties files. The complete list of property files that cocoon-spring-configurator picks up is extensive. If you want to see what’s happening, then add this to log4j.xml:

But there’s one interesting bit in the docs:

9. If a property provider is configured in the application context, it is queried for a set of properties.

If you have special requirements for property handling, you can add a property provider bean which is a Spring managed bean conforming to the org.apache.cocoon.configuration.PropertyProvider interface. For example, if you want to store your configurations inside a database or configure them through a jndi context, you can provide these values through a custom implementation.

So this means that you:

1. Write a class that fetches properties from somewhere like (say) the ServletContext.
2. Add that class into Spring with the name org.apache.cocoon.configuration.PropertyProvider.

So I did that. The code itself is moderately simple:

public class ContextParamsProvider implements PropertyProvider, ServletContextAware {
    public Properties getProperties(Settings settings, String runningMode,
            String path) {
        Properties props = new Properties();
        EnumerationString en = servletContext.getInitParameterNames();
        while (en.hasMoreElements()) {
            String name = en.nextElement();
            String value = servletContext.getInitParameter(name);
            props.setProperty(name, value);
        }
        return props;
    }
}

This should mean that things like what email to send to can be completely external to the application.