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.
[1] http://www.springframework.org/docs/reference/resources.html#d0e6335
--
Leszek Gawron CTO at MobileBox Ltd.
