[jira] [Created] (COCOON-2353) Cocoon 2.2 in servlet 3.0 environment fails to initialize when webjars present on classpath.
Leszek Gawron created COCOON-2353:
-
Summary: Cocoon 2.2 in servlet 3.0 environment fails to initialize
when webjars present on classpath.
Key: COCOON-2353
URL: https://issues.apache.org/jira/browse/COCOON-2353
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2
Reporter: Leszek Gawron
have found a problem that prevents deploying cocoon to 3.0 containers if the
webapp contains webjars - by webjar I mean a jar containing META-INF/resources
folder which is specially treated by sevlet container (the resources from that
folder are served by container itself bypassing any webapp setup).
This happens on jetty 9.x. No matter if I set webapp to be 2.5 servlet
compliant or 3.0.
Does not happen on jetty 8 which is ancient as of now.
I try running my app in embedded Jetty 9 - it works - as long as there is no
actual .war - there is no scanning for META-INF resources.
As soon as I build a war this is how a configured context looks like:
startup of context o.e.j.w.WebAppContext@5bcab519{/,[
file:///C:/cygwin/tmp/jetty-0.0.0.0-8080-root.war-_-any-1513195852101013802.dir/webapp/,
jar:file:///C:/temp/jetty/mywebapp/smart-libs/modernizr-2.8.3.jar!/META-INF/resources,
jar:file:///C:/temp/jetty/mywebapp/smart-libs/openlayers-3.2.0.jar!/META-INF/resources,
jar:file:///C:/temp/jetty/mywebapp/smart-libs/bootstrap-3.3.2.jar!/META-INF/resources,
jar:file:///C:/temp/jetty/mywebapp/smart-libs/jquery-1.11.1.jar!/META-INF/resources],UNAVAILABLE}
{C:\temp\jetty-gemini\gemini/root.war}
suddenly there is more than one root for static resources.
This yields following error:
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'org.apache.cocoon.Processor': Initialization of bean failed; nested
exception is org.springframework.beans.factory.BeanCreationException: Unable to
initialize Avalon component with role org.apache.cocoon.Processor; nested
exception is org.apache.avalon.framework.configuration.ConfigurationException:
Cannot resolve context://sitemap.xmap
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:547)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:759)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
at
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
at
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:843)
at
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:533)
at
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:816)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:345)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:778)
at
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:41)
at
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
at
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:499)
at
[jira] [Commented] (COCOON-2347) Make Cocoon 2.2 compatible with latest Spring Framework 4.2.x version
[ https://issues.apache.org/jira/browse/COCOON-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15180492#comment-15180492 ] Leszek Gawron commented on COCOON-2347: --- I am very interested in making this work. I can spend some time - still to start I need to get some pointers from people more experienced in pipeline stuff. What do I look for to get these exceptions resolved? > Make Cocoon 2.2 compatible with latest Spring Framework 4.2.x version > - > > Key: COCOON-2347 > URL: https://issues.apache.org/jira/browse/COCOON-2347 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core, - Components: Sitemap, - Expression > language, - Servlet service framework >Affects Versions: 2.2 >Reporter: Gabriel Gruber >Assignee: Javier Puerto > Attachments: AbstractElementParser.java.patch, > AbstractTestCase.java.patch, BeanMapElementParser.java.patch, > BridgeElementParser.java.patch, CallScope.java.patch, > MockRequestAttributes.java.patch, MultiMap.java, MultiValueMap.java, > ObjectModel.java.patch, ObjectModelImpl.java.patch, > PipelineComponentInfoInitializerDecorator.java.patch, > PipelineComponentScope.java.patch, ServletDecorator.java.patch, > ServletScope.java.patch, SitemapElementParser.java.patch, > SourceResource.java.patch, WildcardBeanMap.java.patch > > > The goal of this ticket is to make the current Cocoon TRUNK of 2.2 compatible > with latest Spring Framework version. > According to research and feedback in mailinglist following projects (maven > modules) are affected: > - cocoon-spring-configurator > - cocoon-servlet-service-impl > - cocoon-sitemap-impl > - cocoon-pipeline-impl > - cocoon-expression-api > - cocoon-expression-language-impl > .. > Let's discuss problems, and append patches here and someone of the committers > can then apply them to SVN. > Original mail thread: http://markmail.org/message/kkdxrsjqoan6mhr6 > SVN branches: > * https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_2_COCOON-2347 > * > https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/branches/COCOON-2347 > * > https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/branches/COCOON-2347 > Jenkins job: https://builds.apache.org/job/Cocoon 2.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Commented: (COCOON-1978) JXTemplate often fail a method call without giving any error
[
https://issues.apache.org/jira/browse/COCOON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532595
]
Leszek Gawron commented on COCOON-1978:
---
looks like there is no way to fix this without invading Jexl source:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/75481
JXTemplate often fail a method call without giving any error
Key: COCOON-1978
URL: https://issues.apache.org/jira/browse/COCOON-1978
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
Assignee: Leszek Gawron
When calling a method on an instance in JXTemplate, if that method does not
exist (or JX cannot find the proper method based on parameters), it fails
without any error. IMO it should raise an error, or at least should raise it
in dev mode, because not having a debugger it takes hours to figure out why
it's not working.
As an example, take a JX and try to call a method that does not exist :
jx:set var=any
value=${obj.getSomethingThatDoesNotExist(cocoon.request)}/
Any will simply be null. Moreover, even if any is then used :
${any.getSomethingElse()}
Again it will fail without any error, resulting simply in an empty string,
making it even harder.
Being a non compiled language already makes it difficult to make sure calls
are correct, having this silent fail behavior makes it even harder, and if
you add also the non typized nature it can make it a nightmare.
Anyway, I don't know if there is a way to fix this in cocoon or if it is a
Jexl design problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2127) Variable defined by using jx:set is not available outside wrapping element.
[ https://issues.apache.org/jira/browse/COCOON-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron reassigned COCOON-2127: - Assignee: Leszek Gawron (was: Grzegorz Kossakowski) Variable defined by using jx:set is not available outside wrapping element. --- Key: COCOON-2127 URL: https://issues.apache.org/jira/browse/COCOON-2127 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Fix For: 2.2-dev (Current SVN) Leszek has reported in jx:set instruction, more details in these posts: http://article.gmane.org/gmane.text.xml.cocoon.devel/74948 http://article.gmane.org/gmane.text.xml.cocoon.devel/74950 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2127) Variable defined by using jx:set is not available outside wrapping element.
[ https://issues.apache.org/jira/browse/COCOON-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron closed COCOON-2127. - Resolution: Fixed Affects version (Component): Parent values: Blocks: Template(10171). Level 1 values: 1.0.0-RC1(10193). Fix version (Component): Parent values: Blocks: Template(10243). Level 1 values: 1.0.0-RC1(10265). Variable defined by using jx:set is not available outside wrapping element. --- Key: COCOON-2127 URL: https://issues.apache.org/jira/browse/COCOON-2127 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Fix For: 2.2-dev (Current SVN) Leszek has reported in jx:set instruction, more details in these posts: http://article.gmane.org/gmane.text.xml.cocoon.devel/74948 http://article.gmane.org/gmane.text.xml.cocoon.devel/74950 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2130) Migrate cocoon-template from Avalon to Spring
[ https://issues.apache.org/jira/browse/COCOON-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron reassigned COCOON-2130: - Assignee: Leszek Gawron Migrate cocoon-template from Avalon to Spring - Key: COCOON-2130 URL: https://issues.apache.org/jira/browse/COCOON-2130 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Priority: Minor We should migrate cocoon-template from Avalon to Spring for several reasons: * migration to Spring is our long-term goal in general * we could reduce cocoon-template block depedencies greatly and maybe even completely remove dependency on cocoon-core Second point is quite important because it would allow people to use cocoon-template outside Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1978) JXTemplate often fail a method call without giving any error
[
https://issues.apache.org/jira/browse/COCOON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leszek Gawron reassigned COCOON-1978:
-
Assignee: Leszek Gawron
JXTemplate often fail a method call without giving any error
Key: COCOON-1978
URL: https://issues.apache.org/jira/browse/COCOON-1978
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
Assignee: Leszek Gawron
When calling a method on an instance in JXTemplate, if that method does not
exist (or JX cannot find the proper method based on parameters), it fails
without any error. IMO it should raise an error, or at least should raise it
in dev mode, because not having a debugger it takes hours to figure out why
it's not working.
As an example, take a JX and try to call a method that does not exist :
jx:set var=any
value=${obj.getSomethingThatDoesNotExist(cocoon.request)}/
Any will simply be null. Moreover, even if any is then used :
${any.getSomethingElse()}
Again it will fail without any error, resulting simply in an empty string,
making it even harder.
Being a non compiled language already makes it difficult to make sure calls
are correct, having this silent fail behavior makes it even harder, and if
you add also the non typized nature it can make it a nightmare.
Anyway, I don't know if there is a way to fix this in cocoon or if it is a
Jexl design problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2134) StringTemplateParserVariableResolver does not implement Disposable interface
[ https://issues.apache.org/jira/browse/COCOON-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron reassigned COCOON-2134: - Assignee: Leszek Gawron (was: Grzegorz Kossakowski) StringTemplateParserVariableResolver does not implement Disposable interface Key: COCOON-2134 URL: https://issues.apache.org/jira/browse/COCOON-2134 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Priority: Critical Fix For: 2.2-dev (Current SVN) As Csaba Kazó pointed out in comment on COCOON-2106 StringTemplateParserVariableResolver doesn't implement Disposable interface. This may lead to following error: java.lang.ClassCastException: org.apache.cocoon.components.treeprocessor.variables.StringTemplateParserVariableResolver cannot be cast to org.apache.avalon.framework.activity.Disposable at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.dispose(ConcreteTreeProcessor.java:333) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2134) StringTemplateParserVariableResolver does not implement Disposable interface
[ https://issues.apache.org/jira/browse/COCOON-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron closed COCOON-2134. - Resolution: Fixed removed Disposable interface VariableResolverFactory does not register StringTemplateParserVariableResolver for disposal StringTemplateParserVariableResolver does not implement Disposable interface Key: COCOON-2134 URL: https://issues.apache.org/jira/browse/COCOON-2134 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Priority: Critical Fix For: 2.2-dev (Current SVN) As Csaba Kazó pointed out in comment on COCOON-2106 StringTemplateParserVariableResolver doesn't implement Disposable interface. This may lead to following error: java.lang.ClassCastException: org.apache.cocoon.components.treeprocessor.variables.StringTemplateParserVariableResolver cannot be cast to org.apache.avalon.framework.activity.Disposable at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.dispose(ConcreteTreeProcessor.java:333) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1913) [PATCH] ContainerTestCase in cocoon-core should be abstract
[ http://issues.apache.org/jira/browse/COCOON-1913?page=all ] Leszek Gawron closed COCOON-1913. - Resolution: Fixed applied, thank you [PATCH] ContainerTestCase in cocoon-core should be abstract --- Key: COCOON-1913 URL: http://issues.apache.org/jira/browse/COCOON-1913 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-abstract-containertestcase.patch ContainerTestCase is a TestCase class in cocoon-core that helps setting up an environment for container-dependent test cases. The class itself does not provide any test methods and could be made abstract. When running tests with Eclipse's built-in JUnit testrunner, empty test cases (even superclasses of actual test cases) are regarded as failure, while abstract super classes of test cases are ignored. Making ContainerTestCase abstract would help users of the Eclipse IDE that are writing container-dependent test cases. -- 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-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=comments#action_12433583 ] Leszek Gawron commented on COCOON-1912: --- Why do you declare a dependency on logkit? AFAIR we have removed logkit completely. [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- 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-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=comments#action_12433589 ] Leszek Gawron commented on COCOON-1912: --- I have tried to run it also without excalibur components - also works. Are you sure you need them? [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- 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] Closed: (COCOON-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=all ] Leszek Gawron closed COCOON-1912. - Resolution: Fixed Current test pass. [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- 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] Closed: (COCOON-1911) [PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes
[ http://issues.apache.org/jira/browse/COCOON-1911?page=all ] Leszek Gawron closed COCOON-1911. - Resolution: Fixed Patch applied. Thank you [PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes - Key: COCOON-1911 URL: http://issues.apache.org/jira/browse/COCOON-1911 Project: Cocoon Issue Type: Improvement Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-jcr-test-dependency.patch The Cocoon JRC block impl uses in its test cases the ContainerTestCase which is part of the test classes of cocoon-core. The attached patch adds a depdendency to the test-jar of cocoon-core for the test scope. -- 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] Assigned: (COCOON-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=all ] Leszek Gawron reassigned COCOON-1910: - Assignee: Leszek Gawron cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=comments#action_12432811 ] Leszek Gawron commented on COCOON-1910: --- I probably know what causes the problem: cocoon:deploy plugin flattens properties structure. zipExtractor.addRule(META-INF/properties/**, new SingleFileDeployer(WEB-INF/cocoon/properties)); So META-INF/properties/core.properties META-INF/properties/dev/core.properties both end up in webapp/WEB-INF/cocoon/properties/core.properties. That is what causes the failure. My advice is: for the time being rename cocoon-core/src/main/resources/META-INF/properties/dev/core.properties to some other name and rebuild cocoon-core. I'll try to come up with some fix to zip extractor. cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=comments#action_12432817 ] Leszek Gawron commented on COCOON-1910: --- I'm looking into it right now. cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=comments#action_12432823 ] Leszek Gawron commented on COCOON-1910: --- Fixed with a hacky trick. I'll refactor SingleFileDeployer a little bit later. cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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] Closed: (COCOON-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=all ] Leszek Gawron closed COCOON-1910. - Resolution: Fixed cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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_12432504
]
Leszek Gawron commented on COCOON-1898:
---
Concerning src/main/xpatch:
We have have agreed some time ago to keep all the specific cocoon resources in
resources/META-INF subdirectory (spring context, avalon contexts, properties,
sitemap additions and now xpatch). Why make exceptions for xpatches?
On the other side If the resulting jar file contains patches in META-INF/xpatch
it really _should_ not matter whey they are picked from in the first place.
Unfortunately it does. There is one small problem with development blocks
mounted like this:
plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-deployer-plugin/artifactId
version1.0.0-M2-SNAPSHOT/version
configuration
useShieldingClassloaderfalse/useShieldingClassloader
useShieldingRepositoryfalse/useShieldingRepository
blocks
developmentBlock
groupIdcom.mobilebox.donnelley/groupId
artifactIddonnelley-block-common/artifactId
localPath../donnelley-block-common/localPath
/developmentBlock
/blocks
/configuration
/plugin
this configuration is converted later on to a mount in sitemap:
map:match pattern=blocks/donnelley-block-common/**
map:mount uri-prefix=blocks/donnelley-block-common
src=file:/c:/dev/projects/donnelley/donnelley-admin/../donnelley-block-common/src/main/resources/COB-INF//
/map:match
map:match pattern=blocks/donnelley-admin/**
map:mount uri-prefix=blocks/donnelley-admin
src=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/COB-INF//
/map:match
The path is being built like this:
private static final String RESOURCES_DIR = src/main/resources/;
public void setLocalPath(String localPath) throws FileNotFoundException {
File localPathDir = new File(localPath);
if (!localPathDir.exists()) {
throw new FileNotFoundException(Directory ' + localPath + ' does not
exist!);
}
springConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/spring));
xconfConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/legacy/xconf));
sitemapAdditionsConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/legacy/sitemap-additions));
xPatchPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/xpatch));
targetClassesPath = checkDir(new File(localPath, target/classes));
cobInfPath = checkDir(new File(localPath, RESOURCES_DIR + COB-INF));
}
Statically. If you configure something else as a resource folder - it won't be
picked up by cocoon:deploy. We probably would have to use maven API to parse
appropriate pom.xml files.
We should follow both maven and cocoon conventions. Otherwise we'll have
pom.xml bloated from the start.
Concerning long command line:
I am not maven expert and have totally no idea how to invoke
create/configure/invoke a plugin from withing another plugin.
The run order should be: compile deploy patch shield. Patch goes before
shielding before shielding modifies web.xml. If you patched after shielding you
would have to permanently choose if you patch towards shielded/non shielded
webapp.
[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:
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432356 ] Leszek Gawron commented on COCOON-1898: --- To tell you the truth I like XPatch syntax better than your solution. You can understand what the xpatch does even if you never seen the syntax before. Your format has to be well described, otherwise it does not look like a patch file at all. XPatch is more similar to a xsl stylesheet, which is good. XPatch due to it's full XPath (no 'c' before 'h' :)) ) support is way more powerful. What is it that you dislike in XPatch. Maybe we could fix it. I want to implement some more features for cocoon:deploy XPatching: 1. the ability to patch any xml file in cocoon webapp by putting the patch file into /src/main/resources/META-INF/xpatch/blocks/myblock/sitemap.xmap.patch.001.description or /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.001.description-here I figured you have the same path resolution in your solution. 2. xpatch sorting: /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.001.description-here /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.002.other-patch-here this way you may control what patch gets applied first 3. xpatching for both development mode and full cocoon webapp 4. xpatch profiles you will be able to apply only some patches depending on what profile you want enabled (dev,prod,test). This may conflict a little bit with 1). [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_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-nameopenSessionInViewFilter/filter-name filter-class org.springframework.orm.hibernate3.support.OpenSessionInViewFilter /filter-class /filter filter-mapping filter-nameopenSessionInViewFilter/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-nameAcegi Filter Chain Proxy/filter-name filter-classorg.acegisecurity.util.FilterToBeanProxy/filter-class init-param param-nametargetClass/param-name param-valueorg.acegisecurity.util.FilterChainProxy/param-value /init-param /filter filter-mapping filter-nameAcegi Filter Chain Proxy/filter-name url-pattern/*/url-pattern /filter-mapping and listener listener-classorg.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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432371 ] Leszek Gawron commented on COCOON-1898: --- Lars, I've been looking into XUpdate and it is promising. I had no idea this kind of language was already implemented. I think it is some solution between current XPatch and Simone's proposal. Simone, would you care to look into also? http://www.xmldatabases.org/projects/XUpdate-UseCases/ http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html What I like about it the most is the fact that it's externally documented :) Most useful things I learned in cocoon last weeks I got from browsing a source code because the documentation was simply inexistent. [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_12432375 ] Leszek Gawron commented on COCOON-1898: --- This would probably be a good idea if cocoon:deploy had no xpatching abilities. A separate XPatch/XUpdate plugin could be fired. The only thing I really dislike is the probable command line: mvn clean war:exploded cocoon:deploy cocoon:xupdate jetty:run -o -Dmaven.test.skip=true couldn't we make it any shorter. Isn't there any way to have only: mvn clean cocoon:build jetty:run? I do not want to have cocoon war'ed or installed into local repository also. That means copying lots of MBytes on my slow laptop's drive. Please advise. [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_12432142 ] Leszek Gawron commented on COCOON-1898: --- I have commited some initial version of xpatch support. There are some bugs and enhancements pending so I am not closing the issue 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
[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
[jira] Closed: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[ http://issues.apache.org/jira/browse/COCOON-1904?page=all ] Leszek Gawron closed COCOON-1904. - Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed applied, thanks [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- 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-1903) [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes
[ http://issues.apache.org/jira/browse/COCOON-1903?page=comments#action_12431260 ] Leszek Gawron commented on COCOON-1903: --- I am already working on the issue. Thanks for help. Also an archetype needs updating. [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes -- Key: COCOON-1903 URL: http://issues.apache.org/jira/browse/COCOON-1903 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-block-deployer-spring-support.patch In revision 436902 cziegeler changed the way a cocoon web application is loaded in order to provide better spring support. This change had been applied to the cocoon-webapp example web application, but not to the mininmal web application configuration provided by the cocoon-block-deployer maven plugin resulting in breaking the mvn cocoon:deploy jetty6:run target used for developing custom blocks in trunk. (In effect class org.apache.cocoon.servlet.CocoonServletListener could not found) The attached patch updates the web.xml provided by the cocoon-block-deployer to use org.springframework.web.context.ContextLoaderListener instead of org.apache.cocoon.servlet.CocoonServletListener, adds an applicationContext.xml to the cocoon-block-deployer and makes cocoon-block-deployer deploy this applicationContext.xml additionally to web.xml. -- 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-1535) [PATCH] enhancement to {global:} input module: return all sitemap globals
[
http://issues.apache.org/jira/browse/COCOON-1535?page=comments#action_12430426
]
Leszek Gawron commented on COCOON-1535:
---
I do not like that condition to be dropped:
-if ( end == start )
-throw new MalformedURLException(Malformed uri for xmodule source
(cannot find attribute name) : + uri);
What do you think about generate src=xmodule:global:*/ ?
[PATCH] enhancement to {global:} input module: return all sitemap globals
-
Key: COCOON-1535
URL: http://issues.apache.org/jira/browse/COCOON-1535
Project: Cocoon
Issue Type: Bug
Components: - Components: Avalon
Affects Versions: 2.1.8
Environment: Operating System: other
Platform: Other
Reporter: Mark Lundquist
Assigned To: Cocoon Developers Team
Attachments: patch
If invoked with an empty attribute name, serializes all the global variables
to a SAX stream all in one
whack. This allows for the following:
match pattern=globals
generate src=xmodule:global: /
serialize
/match
The idea is that this pipeline is a convnient way to get visibility to
sitemap globals from within an XSLT
stylesheet, without having to pass them in as stylesheet parameters.
This patch also relaxes XModuleSource to accept an input module name with an
empty attribute name.
It should be up to the input module whether an empty attribute is valid.
--
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] Assigned: (COCOON-1744) NullPointerException in template block
[ http://issues.apache.org/jira/browse/COCOON-1744?page=all ] Leszek Gawron reassigned COCOON-1744: - Assign To: Leszek Gawron NullPointerException in template block -- Key: COCOON-1744 URL: http://issues.apache.org/jira/browse/COCOON-1744 Project: Cocoon Type: Bug Components: Blocks: Templating Versions: 2.2-dev (Current SVN) Reporter: Tim Williams Assignee: Leszek Gawron Priority: Minor Attachments: template_block.patch I have been unsuccessful actually building Cocoon so this is an untested patch. Can someone take a look and, if ok, apply to the template block? Thanks, --tim -- 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] Assigned: (COCOON-1737) JXTemplate Generater: set var problem
[ http://issues.apache.org/jira/browse/COCOON-1737?page=all ]
Leszek Gawron reassigned COCOON-1737:
-
Assign To: Leszek Gawron
JXTemplate Generater: set var problem
-
Key: COCOON-1737
URL: http://issues.apache.org/jira/browse/COCOON-1737
Project: Cocoon
Type: Bug
Components: Blocks: Templating
Versions: 2.1.9-dev (current SVN)
Reporter: Werner Masik
Assignee: Leszek Gawron
Priority: Minor
It looks to me like something is wrong with jx:set var= . AFAIK set var
just is a alias and can be used like any other variable in the template. But
it is not possible to use it in a attribute value.
example:
jx:set var=testvar value=hello /
somexmlmyattr=${testvar} /
leads to something like:
somexmlmyattr=[Lorg.w3c.dom.Node;@1abcd5e /
Obviously not the content of the variable is returned, but the reference to
the DOM-node. It works normal if it is used within the body.
This problem might be related to
https://issues.apache.org/jira/browse/COCOON-1417
--
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
