[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431829 ] Leszek Gawron commented on COCOON-1898: --- Main sitemap. Not always a block can be tested in total isolation. Just as the block may require some servlet filters (e.g. hibernate3.OpenSessionInViewFilter) it also might need some additional sitemap entries (e.g. mounting external resources). I do not like the fact that in current patch the directory is located in module-dir/conf. I'd like the patch files to be put under src/main/resources/META-INF/xpatch. This way they go into the artifact jar and then the following scenario is possible: Every block (say myapp-block-admin-interface, myapp-block-client-interface) needs transactions. I define a myapp-block-core block that has an appropriate applicationContext.xml (dataSource, transactionManager and such) and xpatch file that defines a servlet filter (hibernate3.OpenSessionInViewFilter). Simply declaring a dependency on myapp-block-core in myapp-block-admin-interface is sufficient to have my web.xml patched for local development. When a project has a significant number of modules it is way more convenient for the core block to bring xpatch along with itself rather than define a xpatch file for each module that needs it. We could apply the same logic for xpath files as for settings: profiles. Some xpatch files will be no matter what. Some will be only applied in development mode. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431830 ] Leszek Gawron commented on COCOON-1898: --- Writing main sitemap I meant the one that is generated by cocoon:deploy automatically thus the user has no control over it. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431967 ] Leszek Gawron commented on COCOON-1898: --- The patch needs some polishing. Working on it now. [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
MonolithicServer22 and file deploying
Is there any reason for:
out = fileDeployer.writeResource(document.getName());
ByteArrayOutputStream baos = new ByteArrayOutputStream();
// loop over ZIP entry stream
byte[] buffer = new byte[8192];
int length = -1;
while (zipStream.available() 0) {
length = zipStream.read(buffer, 0, 8192);
if (length 0) {
baos.write(buffer, 0, length);
}
}
// write it to the output stream provided by the file resource manager
out.write(baos.toByteArray());
instead of
out = new BufferedOutputStream(
fileDeployer.writeResource(document.getName()));
// loop over ZIP entry stream
byte[] buffer = new byte[8192];
int length;
while ((length = zipStream.read(buffer)) 0) {
out.write(buffer, 0, length);
}
?
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: MonolithicServer22 and file deploying
Leszek Gawron wrote:
Is there any reason for:
as the deployer has a very looong history, this part changed many times. your
replacement looks good to me. if it works, go for it.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: MonolithicServer22 and file deploying
Reinhard Poetz wrote: Leszek Gawron wrote: Is there any reason for: as the deployer has a very looong history, this part changed many times. your replacement looks good to me. if it works, go for it. It does. I have already a production site running on mavenized cocoon 2.2 - I'll know soon enough if I break something :) -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
