cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [2.2] Deployment and the maven plugin
Date Fri, 03 Nov 2006 08:41:43 GMT
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> My intention for i) was the ability for the block to contribute to 
>> web.xml. You can create yourself a OpenSessionInViewBlock.jar which, 
>> during deployment, will automatically enable the proper filter in 
>> web.xml. As my web.xmls in different projects stay very alike I would 
>> like to extract the common definitions into a reusable artifact.
>> This goes to any stuff that you need to put into web xml:
>> - filters
>> - listeners
>> - additional servlets (AFAIR some of the users used .xpath files to 
>> include xindice servlets in web.xml)
>> My common design in: webapp depends on ui-block (contributes COB-INF) 
>> depends on core block (contributes model and spring services) depends on 
>> hibernate and opensessioninview (contributes filters to web.xml)
> Ok, I see - obviously we can't patch the web.xml at runtime as its too
> late then, so this has to be done during deployment (or packaging).
> I think we could leave this functionality in the our plugin for now, but
> I would love to have such support directly in the maven webapp plugin.
> The same for the shielded classloading stuff. This would free us from
> having to use Cocoon specific plugins for non-Cocoon specific things.
>> First of all: why don't we simply use spring functionality for that? 
>> Spring has a nice resource resolution. Why don't we simply reference
>> classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
>> classpath*:/META-INF/cocoon/properties/*.properties, 
>> classpath*:/META-INF/cocoon/properties/{currentmode}/*.properties
>> for properties resolution?
> Does this work in Spring? I briefly looked at the code but did not find
> support for patterns when using the classpath protocol. *If* this is
> working we can directly read these files from within the jars without
> need to extract anything. That should be simple.

It sure is. I am setting up my tools/test cases like this:

> public abstract class AbstractSpringTool {
> 	protected static final Log					logger	= LogFactory.getLog( AbstractSpringTool.class
> 	protected ConfigurableApplicationContext	context;
> 	public AbstractSpringTool() {
> 		this.context = new ClassPathXmlApplicationContext( getContextLocation() );
> 		this.context.getBeanFactory().autowireBeanProperties(	this,
> 																getAutowireType(),
> 																false );
> 	}
> 	public String[] getContextLocation() {
> 		return new String[] { "classpath*:/META-INF/spring/*.xml" };
> 	}
> 	public int getAutowireType() {
> 		return AutowireCapableBeanFactory.AUTOWIRE_BY_NAME;
> 	}
> 	public abstract void run() throws Exception;
> }

and property placeholders:

> 	<bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> 		<property name="locations" value="classpath*:META-INF/properties/*.properties"/>
> 	</bean>

works like a charm.

If you only pointed me to the location where cocoon/spring/* are 
enumerated I will do the necessary changes.

You can even use ant style wildcards. The only thing you cannot do is 
classpath*:*.xml. You have to at least reference a single directory in 
the path. The appropriate docs can be found here [1]

>> Could the archetype stop putting cocoon.xconf into generated webapp?
> It does not do this anymore (since monday) :)

Superb. I'll test the changes today.


Leszek Gawron                                    CTO at MobileBox Ltd.

View raw message