cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leszek Gawron (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
Date Sun, 03 Sep 2006 19:02:23 GMT
    [ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432369 ] 
            
Leszek Gawron commented on COCOON-1898:
---------------------------------------

putting your xpatch files into /src/main/resources/META-INF/xpatch allows to pack them into
the artifact (jar). This way the patch file can be applied anywhere later just by declaring
a dependency in pom.xml. Example:

myapp-block-core defines a set of application services along with transaction management.
It also provides a patch file that enables OpenSessionInViewFilter for hibernate:

<?xml version="1.0"?>
<xweb xpath="/web-app" unless="comment()[contains(., 'Spring filters')]" insert-before="servlet">
    <!-- Spring filters -->
    <filter>
        <filter-name>openSessionInViewFilter</filter-name>
        <filter-class>
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
        </filter-class>
    </filter>
    <filter-mapping>
        <filter-name>openSessionInViewFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</xweb>

the application also has an administration interface: myapp-block-admin-interface. It is sufficient
to declare a dependency on myapp-block-core in myapp-block-admin-interface's pom.xml file
and you will be able to do:

myapp-block-admin-interface> mvn clean compile cocoon:deploy jetty:run

having access to all core's services and OpenSessionInViewFilter properly declared in web.xml.


If you have a single block that uses core  your proposal would be fine. You could put the
xpatch file locally to myapp-block-admin-interface/src/main/xpatch and get it applied while
testing administration interface. But imagine your application consists of 20 blocks every
depending on core. Every block would have to keep it's own copy of xpatch file to have core
working properly. ugly :)

It is nothing unusual that several patches target one file. Extending my example:

myapp-block-core provides transaction management and provides a patch for OpenSessionInViewFilter
myapp-block-security provides acegisecurity services that need 2 patches in web.xml:

<filter>
	<filter-name>Acegi Filter Chain Proxy</filter-name>
	<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
	<init-param>
		<param-name>targetClass</param-name>
		<param-value>org.acegisecurity.util.FilterChainProxy</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>Acegi Filter Chain Proxy</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

and 
<listener>
	<listener-class>org.acegisecurity.ui.session.HttpSessionEventPublisher</listener-class>
</listener>

My 2.1.x production sites also have 3-7 patches targeting cocoon.xconf. As long as they did
not impose ordering constraints I prefered to keep them in several files and reuse in different
projects. In few rare cases you need to insert data in a specified order (like servlet filters).
Then the xpatch ordering I was describing comes into play.

> [PATCH] XPatch support for maven-cocoon-deployer-plugin
> -------------------------------------------------------
>
>                 Key: COCOON-1898
>                 URL: http://issues.apache.org/jira/browse/COCOON-1898
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: - Build System: Maven
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Lars Trieloff
>         Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch
>
>
> The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult
to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block
should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet.
This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current
state of the deployer-plugin.
> My patch adds support for patching the web.xml file using *.xweb files in the /conf directory
of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching
the patch document temporarily and applying them (using code from the orgiginal XConfToolTask
in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb
files and does not support any property expansion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message