[
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
