[jira] [Updated] (COCOON3-65) Provide documentation for the cocoon-spring-configurator items (sitemap reload, exception unroll)
[ https://issues.apache.org/jira/browse/COCOON3-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON3-65: -- Fix Version/s: 3.0.0 > Provide documentation for the cocoon-spring-configurator items (sitemap > reload, exception unroll) > - > > Key: COCOON3-65 > URL: https://issues.apache.org/jira/browse/COCOON3-65 > Project: Cocoon 3 > Issue Type: Task > Components: cocoon-servlet, cocoon-sitemap >Reporter: Francesco Chicchiriccò >Priority: Minor > Fix For: 3.0.0 > > > As per mail thread at > http://www.mail-archive.com/dev@cocoon.apache.org/msg59689.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated COCOON3-85:
--
Fix Version/s: (was: 3.0.0-beta-1)
3.0.0
> cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's
> static optimizer
>
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
>Reporter: Igor Malinin
> Fix For: 3.0.0
>
> Attachments: java.patch
>
>
> As reported at first in mailing list [1], AspectJ's static optimizer was
> reviewed starting from 1.6.7 onward.
> A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
> (quite ancient right now).
> At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
> versions.
> With Spring 3.1, this workaround is not enough any more.
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
> [1]
> http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: cocoon spring configurator 2.2.1 usable only in web environment?
On 2012-08-14 12:30, Francesco Chicchiriccò wrote: On 14/08/2012 12.15, Leszek Gawron wrote: After migrating from 1.0.3 to 2.2.1 I am getting the following exception when running unit tests that use Hi Leszek, by taking a look at [1], I couldn't see any 1.0.3, only 1.0.2: how did you get 1.0.3? built myself :) I forgot that there were some fixes never released in 1.0.x branch so I've built a local relase myself. Anyway, could you please take some gradual update 1.0.2->2.0.0, then 2.0.0->2.1.0, finally 2.1.0->2.2.1 in order to help finding at which point in history this was introduced? My bad. I had cocoon-block-deployment on my classpath. Removing it fixed the issue. [1] is a little bit misleading. [1] http://cocoon.apache.org/subprojects/configuration/spring-configurator/1474_1_1.html -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox S.A.
Re: cocoon spring configurator 2.2.1 usable only in web environment?
On 14/08/2012 12.15, Leszek Gawron wrote: After migrating from 1.0.3 to 2.2.1 I am getting the following exception when running unit tests that use readFromGlobalLocation="false"/> Hi Leszek, by taking a look at [1], I couldn't see any 1.0.3, only 1.0.2: how did you get 1.0.3? Anyway, could you please take some gradual update 1.0.2->2.0.0, then 2.0.0->2.1.0, finally 2.1.0->2.2.1 in order to help finding at which point in history this was introduced? Thanks. Regards. [1] http://central.maven.org/maven2/org/apache/cocoon/cocoon-spring-configurator/ ERROR 2012-08-14 12:03.39:868 [ TestContextManager] Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@3c76da81] to prepare test instance [com.mobilebox.smart.polka.importer.test.PerformImportTool@1f036a2a] java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75) at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory' defined in URL [jar:file:/C:/devtools/m2/repository/org/apache/cocoon/cocoon-block-deployment/1.2.1/cocoon-block-deployment-1.2.1.jar!/META-INF/cocoon/spring/cocoon-blockdeployment-protocol.xml]: Initialization of bean failed; nested exception is java.lang.ClassCastException: org.springframework.context.support.GenericApplicationContext cannot be cast to org.springframework.web.context.WebApplicationContext at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(Defaul
cocoon spring configurator 2.2.1 usable only in web environment?
After migrating from 1.0.3 to 2.2.1 I am getting the following exception when running unit tests that use readFromGlobalLocation="false"/> ERROR 2012-08-14 12:03.39:868 [TestContextManager] Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@3c76da81] to prepare test instance [com.mobilebox.smart.polka.importer.test.PerformImportTool@1f036a2a] java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75) at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory' defined in URL [jar:file:/C:/devtools/m2/repository/org/apache/cocoon/cocoon-block-deployment/1.2.1/cocoon-block-deployment-1.2.1.jar!/META-INF/cocoon/spring/cocoon-blockdeployment-protocol.xml]: Initialization of bean failed; nested exception is java.lang.ClassCastException: org.springframework.context.support.GenericApplicationContext cannot be cast to org.springframework.web.context.WebApplicationContext at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469) at org.springframework.test.context.support.AbstractG
[RESULT] [VOTE] Apache Cocoon Spring Configurator 2.2.1
Hi all, after 72 hours, the vote for Cocoon Spring Configurator 2.2.1 [1] *passes* with 4 PMC + 0 non-PMC votes. +1 (PMC / binding) * Robby Pelssers * Peter Hunsberger * Simone Tripodi * Francesco Chicchiriccò +1 (non binding) 0 -1 Thanks to everyone participating. I will now copy this release to Cocoon' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://markmail.org/message/righ6e3anpsxu646 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon Spring Configurator 2.2.1
On 15/06/2012 09:56, Francesco Chicchiriccò wrote: > I've created a Cocoon Spring Configurator 2.2.1 release, with the > following artifacts up for a vote: > > SVN source tag (r1350510): > https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/ > > List of changes: > https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/src/changes/changes.xml > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachecocoon-242/ > > Source release (checksums and signatures are available at the same > location): > https://repository.apache.org/content/repositories/orgapachecocoon-242/org/apache/cocoon/cocoon-spring-configurator/2.2.1/cocoon-spring-configurator-2.2.1-source-release.zip > > PGP release keys (signed using 273DF287): > http://www.apache.org/dist/cocoon/KEYS > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) +1 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon Spring Configurator 2.2.1
+1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 10:38 PM, Peter Hunsberger wrote: > +1 > Peter Hunsberger > > > > On Fri, Jun 15, 2012 at 2:56 AM, Francesco Chicchiriccò > wrote: >> >> I've created a Cocoon Spring Configurator 2.2.1 release, with the >> following artifacts up for a vote: >> >
Re: [VOTE] Apache Cocoon Spring Configurator 2.2.1
+1 Peter Hunsberger On Fri, Jun 15, 2012 at 2:56 AM, Francesco Chicchiriccò wrote: > I've created a Cocoon Spring Configurator 2.2.1 release, with the > following artifacts up for a vote: > >
RE: [VOTE] Apache Cocoon Spring Configurator 2.2.1
+1 -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Friday, June 15, 2012 9:57 AM To: dev@cocoon.apache.org Subject: [VOTE] Apache Cocoon Spring Configurator 2.2.1 I've created a Cocoon Spring Configurator 2.2.1 release, with the following artifacts up for a vote: SVN source tag (r1350510): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-242/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-242/org/apache/cocoon/cocoon-spring-configurator/2.2.1/cocoon-spring-configurator-2.2.1-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[VOTE] Apache Cocoon Spring Configurator 2.2.1
I've created a Cocoon Spring Configurator 2.2.1 release, with the following artifacts up for a vote: SVN source tag (r1350510): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/tags/cocoon-spring-configurator-2.2.1/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-242/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-242/org/apache/cocoon/cocoon-spring-configurator/2.2.1/cocoon-spring-configurator-2.2.1-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: cocoon-spring-configurator issue
On 29/02/2012 08:29, Reinhard Pötz wrote:
On 02/28/2012 09:59 PM, Leszek Gawron wrote:
[...]
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties( beanFactoryToProcess,
new SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
Go ahead! I will test with our projects in order to give feedback
about unwanted side effects.
After testing that C3 build wasn't affected by this change, I've just
committed the change provided [1].
Regards.
[1]
http://svn.apache.org/viewvc/cocoon/subprojects/cocoon-spring-configurator/trunk/src/main/java/org/apache/cocoon/spring/configurator/impl/AbstractSettingsBeanFactoryPostProcessor.java?rev=1343741&r1=1343740&r2=1343741&view=diff
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
Re: cocoon-spring-configurator issue
On 02/28/2012 09:59 PM, Leszek Gawron wrote:
Hello,
I tried to upgrade my cocoon based product to use spring 3.0 new
features. One of those is @Value("${propertyName}") annotation.
This feature works for but does not for
cocoon's . This is slightly weird as coocon
configurator theoreticaly bases on PropertyPlaceholderConfigurer.
The issue lies in this code (I used :
cocoon-spring-configurator-1.0.2\src\main\java\org\apache\cocoon\spring\configurator\impl\AbstractSettingsBeanFactoryPostProcessor.java
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
java.util.Properties)
*/
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess,
Properties props)
throws BeansException {
final BeanDefinitionVisitor visitor = new
CocoonSettingsResolvingBeanDefinitionVisitor(this.settings);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (int i = 0; i < beanNames.length; i++) {
BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(beanNames[i]);
try {
visitor.visitBeanDefinition(bd);
} catch (BeanDefinitionStoreException e) {
throw new BeanDefinitionStoreException(bd.getResourceDescription(),
beanNames[i], e);
}
}
}
protected class CocoonSettingsResolvingBeanDefinitionVisitor extends
BeanDefinitionVisitor {
protected final Properties props;
protected final Set visitedPlaceholders = new HashSet();
public CocoonSettingsResolvingBeanDefinitionVisitor( Settings settings
) {
this.props = new SettingsProperties( settings );
}
protected String resolveStringValue( String strVal ) {
return parseStringValue( strVal,
this.props,
visitedPlaceholders );
}
}
This method completely rewrites the super method (from
PropertyPlaceholderConfigurer) which looks like this:
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props)
throws BeansException {
StringValueResolver valueResolver = new
PlaceholderResolvingStringValueResolver(props);
BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(valueResolver);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (String curName : beanNames) {
// Check that we're not parsing our own bean definition,
// to avoid failing on unresolvable placeholders in properties file
locations.
if (!(curName.equals(this.beanName) &&
beanFactoryToProcess.equals(this.beanFactory))) {
BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(curName);
try {
visitor.visitBeanDefinition(bd);
}
catch (Exception ex) {
throw new BeanDefinitionStoreException(bd.getResourceDescription(),
curName, ex.getMessage());
}
}
}
// New in Spring 2.5: resolve placeholders in alias target names and
aliases as well.
beanFactoryToProcess.resolveAliases(valueResolver);
// New in Spring 3.0: resolve placeholders in embedded values such as
annotation attributes.
beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}
As you see new features completely got disabled.
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties( beanFactoryToProcess,
new SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
Go ahead! I will test with our projects in order to give feedback about
unwanted side effects.
--
Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
cocoon-spring-configurator issue
Hello,
I tried to upgrade my cocoon based product to use spring 3.0 new
features. One of those is @Value("${propertyName}") annotation.
This feature works for but does not for
cocoon's . This is slightly weird as coocon
configurator theoreticaly bases on PropertyPlaceholderConfigurer.
The issue lies in this code (I used :
cocoon-spring-configurator-1.0.2\src\main\java\org\apache\cocoon\spring\configurator\impl\AbstractSettingsBeanFactoryPostProcessor.java
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
java.util.Properties)
*/
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess,
Properties props)
throws BeansException {
final BeanDefinitionVisitor visitor = new
CocoonSettingsResolvingBeanDefinitionVisitor(this.settings);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (int i = 0; i < beanNames.length; i++) {
BeanDefinition bd =
beanFactoryToProcess.getBeanDefinition(beanNames[i]);
try {
visitor.visitBeanDefinition(bd);
} catch (BeanDefinitionStoreException e) {
throw new
BeanDefinitionStoreException(bd.getResourceDescription(), beanNames[i], e);
}
}
}
protected class CocoonSettingsResolvingBeanDefinitionVisitor extends
BeanDefinitionVisitor {
protected final Properties props;
protected final Set visitedPlaceholders
= new HashSet();
public CocoonSettingsResolvingBeanDefinitionVisitor( Settings
settings ) {
this.props = new SettingsProperties( settings );
}
protected String resolveStringValue( String strVal ) {
return parseStringValue(strVal,
this.props,
visitedPlaceholders );
}
}
This method completely rewrites the super method (from
PropertyPlaceholderConfigurer) which looks like this:
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props)
throws BeansException {
StringValueResolver valueResolver = new
PlaceholderResolvingStringValueResolver(props);
BeanDefinitionVisitor visitor = new
BeanDefinitionVisitor(valueResolver);
String[] beanNames =
beanFactoryToProcess.getBeanDefinitionNames();
for (String curName : beanNames) {
// Check that we're not parsing our own bean definition,
// to avoid failing on unresolvable placeholders in
properties file locations.
if (!(curName.equals(this.beanName) &&
beanFactoryToProcess.equals(this.beanFactory))) {
BeanDefinition bd =
beanFactoryToProcess.getBeanDefinition(curName);
try {
visitor.visitBeanDefinition(bd);
}
catch (Exception ex) {
throw new
BeanDefinitionStoreException(bd.getResourceDescription(), curName,
ex.getMessage());
}
}
}
// New in Spring 2.5: resolve placeholders in alias target
names and aliases as well.
beanFactoryToProcess.resolveAliases(valueResolver);
// New in Spring 3.0: resolve placeholders in embedded values
such as annotation attributes.
beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}
As you see new features completely got disabled.
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties(beanFactoryToProcess,
new
SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
lg
cocoon-spring-configurator issue
Hello,
I tried to upgrade my cocoon based product to use spring 3.0 new
features. One of those is @Value("${propertyName}") annotation.
This feature works for but does not for
cocoon's . This is slightly weird as coocon
configurator theoreticaly bases on PropertyPlaceholderConfigurer.
The issue lies in this code (I used :
cocoon-spring-configurator-1.0.2\src\main\java\org\apache\cocoon\spring\configurator\impl\AbstractSettingsBeanFactoryPostProcessor.java
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
java.util.Properties)
*/
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess,
Properties props)
throws BeansException {
final BeanDefinitionVisitor visitor = new
CocoonSettingsResolvingBeanDefinitionVisitor(this.settings);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (int i = 0; i < beanNames.length; i++) {
BeanDefinition bd =
beanFactoryToProcess.getBeanDefinition(beanNames[i]);
try {
visitor.visitBeanDefinition(bd);
} catch (BeanDefinitionStoreException e) {
throw new
BeanDefinitionStoreException(bd.getResourceDescription(), beanNames[i], e);
}
}
}
protected class CocoonSettingsResolvingBeanDefinitionVisitor extends
BeanDefinitionVisitor {
protected final Properties props;
protected final Set visitedPlaceholders
= new HashSet();
public CocoonSettingsResolvingBeanDefinitionVisitor( Settings
settings ) {
this.props = new SettingsProperties( settings );
}
protected String resolveStringValue( String strVal ) {
return parseStringValue(strVal,
this.props,
visitedPlaceholders );
}
}
This method completely rewrites the super method (from
PropertyPlaceholderConfigurer) which looks like this:
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props)
throws BeansException {
StringValueResolver valueResolver = new
PlaceholderResolvingStringValueResolver(props);
BeanDefinitionVisitor visitor = new
BeanDefinitionVisitor(valueResolver);
String[] beanNames =
beanFactoryToProcess.getBeanDefinitionNames();
for (String curName : beanNames) {
// Check that we're not parsing our own bean definition,
// to avoid failing on unresolvable placeholders in
properties file locations.
if (!(curName.equals(this.beanName) &&
beanFactoryToProcess.equals(this.beanFactory))) {
BeanDefinition bd =
beanFactoryToProcess.getBeanDefinition(curName);
try {
visitor.visitBeanDefinition(bd);
}
catch (Exception ex) {
throw new
BeanDefinitionStoreException(bd.getResourceDescription(), curName,
ex.getMessage());
}
}
}
// New in Spring 2.5: resolve placeholders in alias target
names and aliases as well.
beanFactoryToProcess.resolveAliases(valueResolver);
// New in Spring 3.0: resolve placeholders in embedded values
such as annotation attributes.
beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}
As you see new features completely got disabled.
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties(beanFactoryToProcess,
new
SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
--
Leszek
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177216#comment-13177216
]
Thorsten Scherler commented on COCOON3-85:
--
I am At revision 1225548.
uname -rios
Linux 3.0.0-14-generic x86_64 GNU/Linux
java -version
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)
c3/cocoon-sample$ mvn clean install jetty:run
now works, weird seems the "clean" did the trick, sorry for the noise and
thanks for testing.
> cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's
> static optimizer
>
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
>Reporter: Igor Malinin
> Fix For: 3.0.0-beta-1
>
> Attachments: java.patch
>
>
> As reported at first in mailing list [1], AspectJ's static optimizer was
> reviewed starting from 1.6.7 onward.
> A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
> (quite ancient right now).
> At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
> versions.
> With Spring 3.1, this workaround is not enough any more.
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
> [1]
> http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177200#comment-13177200
]
Francesco Chicchiriccò commented on COCOON3-85:
---
@Thorsten I've just tried to reproduce the issue with StringTemplate generator
with no luck: no my laptop (Linux 3.1 64bit / OpenJDK 6.0.23) it runs smoothly.
> cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's
> static optimizer
>
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
>Reporter: Igor Malinin
> Fix For: 3.0.0-beta-1
>
> Attachments: java.patch
>
>
> As reported at first in mailing list [1], AspectJ's static optimizer was
> reviewed starting from 1.6.7 onward.
> A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
> (quite ancient right now).
> At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
> versions.
> With Spring 3.1, this workaround is not enough any more.
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
> [1]
> http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[ https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177189#comment-13177189 ] Thorsten Scherler edited comment on COCOON3-85 at 12/29/11 2:23 PM: Actually @Francesco r1224754 broke the Stringtemplate example, meaning it seems that everything is fine but in runtime that is not like that any more. It seems as Igor described a problem of the class loader. Not sure though whether it is "fault" of the RCL or the configurator, but I will try now to apply the patch on my system and look whether that solves the problem. To reproduce, * just mvn clean install current Head * cd cocoon-sample * mvn jetty:run * http://localhost:/string-template/generator -> BANG! 2011-12-29 15:08:16.138:INFO:/:Initializing Spring root WebApplicationContext 2011-12-29 15:08:19.347:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is running in mode 'dev'. 2011-12-29 15:08:23.468:INFO:/:DispatcherServlet: Block dispatcher was initialized successfully. 2011-12-29 15:08:23.581:INFO::Started SelectChannelConnector@0.0.0.0: [INFO] Started Jetty Server 2011-12-29 15:08:35.365:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is running in mode 'dev'. java.lang.Error: Unresolved compilation problem: STRenderer cannot be resolved at org.apache.cocoon.stringtemplate.StringTemplateGenerator.renderTemplate(StringTemplateGenerator.java:152) at org.apache.cocoon.stringtemplate.StringTemplateGenerator.execute(StringTemplateGenerator.java:172) 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:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:91) at org.apache.cocoon.profiling.aspects.InvocationDispatcher.dispatch(InvocationDispatcher.java:68) at org.apache.cocoon.profiling.aspects.PipelineComponentProfilingAspect.handleInvocation(PipelineComponentProfilingAspect.java:41) at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) at $Proxy46.execute(Unknown Source) at org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:150) at org.apache.cocoon.pipeline.AbstractPipeline.execute(AbstractPipeline.java:80) 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:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) at org.apache.cocoon.servlet.collector.ResponseHeaderCollector.interceptInvoke(ResponseHeaderCollector.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.re
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177189#comment-13177189
]
Thorsten Scherler commented on COCOON3-85:
--
Actually @Francesco r1224754 broke the Stringtemplate example, meaning it
seems that everything is fine but in runtime that is not like that any more. It
seems as Igor described a problem of the class loader. Not sure though whether
it is "fault" of the RCL or the configurator, but I will try now to apply the
patch on my system and look whether that solves the problem.
To reproduce,
* just mvn clean install current Head
* cd cocoon-sample
* mvn jetty:run
* http://localhost:/string-template/generator -> BANG!
{{{
2011-12-29 15:08:16.138:INFO:/:Initializing Spring root WebApplicationContext
2011-12-29 15:08:19.347:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is
running in mode 'dev'.
2011-12-29 15:08:23.468:INFO:/:DispatcherServlet: Block dispatcher was
initialized successfully.
2011-12-29 15:08:23.581:INFO::Started SelectChannelConnector@0.0.0.0:
[INFO] Started Jetty Server
2011-12-29 15:08:35.365:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is
running in mode 'dev'.
java.lang.Error: Unresolved compilation problem:
STRenderer cannot be resolved
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.renderTemplate(StringTemplateGenerator.java:152)
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.execute(StringTemplateGenerator.java:172)
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:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:91)
at
org.apache.cocoon.profiling.aspects.InvocationDispatcher.dispatch(InvocationDispatcher.java:68)
at
org.apache.cocoon.profiling.aspects.PipelineComponentProfilingAspect.handleInvocation(PipelineComponentProfilingAspect.java:41)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy46.execute(Unknown Source)
at
org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:150)
at
org.apache.cocoon.pipeline.AbstractPipeline.execute(AbstractPipeline.java:80)
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:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at
org.apache.cocoon.servlet.collector.ResponseHeaderCollector.interceptInvoke(ResponseHeaderCollector.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeM
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176121#comment-13176121
]
Francesco Chicchiriccò commented on COCOON3-85:
---
After re-reading the thread in mailing list, I now (finally :-P) understand
your point.
For this reason I have modified a bit this issue's title and description.
Since we need to apply your patch (and possibly one of the alternatives
considered in mailing list in the original thread [1]) to Cocoon subprojects
(cocoon-spring-configurator) outside of Cocoon 3 own sources, I think we will
also have to wait for proposed Subversion reorganization [2] so that SNAPSHOT
artifacts will be regularly published for these subprojects as well.
[2]
http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html
> cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's
> static optimizer
>
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
>Reporter: Igor Malinin
> Fix For: 3.0.0-beta-1
>
> Attachments: java.patch
>
>
> As reported at first in mailing list [1], AspectJ's static optimizer was
> reviewed starting from 1.6.7 onward.
> A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
> (quite ancient right now).
> At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
> versions.
> With Spring 3.1, this workaround is not enough any more.
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
> [1]
> http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-85) cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated COCOON3-85:
--
Fix Version/s: 3.0.0-beta-1
Priority: Major (was: Critical)
Description:
As reported at first in mailing list [1], AspectJ's static optimizer was
reviewed starting from 1.6.7 onward.
A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
(quite ancient right now).
At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
versions.
With Spring 3.1, this workaround is not enough any more.
One issue I reported already in mailing list when Jetty7 + recent AspectJ was
failing, not the same issue is deeper and ServletContextFactoryBean doesn't
work at all with Spring 3.1.
Note that ServletContext is already in the Spring web-app context, although
with another name ('servletContext'). This is available starting from Spring
3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext' solves
problem partially, but still fails on XMLSitemapServlet initialization (as it
uses static field in ServletContextFactoryBean).
I will attach a patch (a little bit dirty, but not more than the current
implementation). But it assumes at least Spring 3.0.
As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have as
a dependency at leas 3.0 version of Spring Framework (for Java5 generics etc.)
[1]
http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
was:
There are several issues that prevent Cocoon 3 to work with Spring 3.1
One issue I reported already in mailing list when Jetty7 + recent AspectJ was
failing, not the same issue is deeper and ServletContextFactoryBean doesn't
work at all with Spring 3.1.
Note that ServletContext is already in the Spring web-app context, although
with another name ('servletContext'). This is available starting from Spring
3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext' solves
problem partially, but still fails on XMLSitemapServlet initialization (as it
uses static field in ServletContextFactoryBean).
I will attach a patch (a little bit dirty, but not more than the current
implementation). But it assumes at least Spring 3.0.
As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have as
a dependency at leas 3.0 version of Spring Framework (for Java5 generics etc.)
Affects Version/s: 3.0.0-alpha-1
3.0.0-alpha-2
3.0.0-alpha-3
Summary: cocoon-spring-configurator doesn't work with latest (>
1.6.6) AspectJ's static optimizer (was: cocoon-spring-configurator doesn't
work with Spring 3.1)
> cocoon-spring-configurator doesn't work with latest (> 1.6.6) AspectJ's
> static optimizer
>
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
>Reporter: Igor Malinin
> Fix For: 3.0.0-beta-1
>
> Attachments: java.patch
>
>
> As reported at first in mailing list [1], AspectJ's static optimizer was
> reviewed starting from 1.6.7 onward.
> A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
> (quite ancient right now).
> At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
> versions.
> With Spring 3.1, this workaround is not enough any more.
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
> [1]
> http://old.n
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176054#comment-13176054
]
Igor Malinin commented on COCOON3-85:
-
I explained some time ago the roots of the problem on cocoon-dev mailing list
(http://old.nabble.com/Jetty-7---%22can't-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html),
and those are in no way Jetty problem, but the Cocoon!
Jetty is OSGi container and it isolates class loaders. This is perfectly legal
and is not in any violation of Servlet specs. C3 defines a BeanFactory for
ServletContext and then tries to apply AspectJ pointcuts over it, but AspectJ
optimizer fails because it cannot see the Jetty's implementation of
ServletContext. Before Spring 3.1 it was possible to workaround it by using old
AspectJ versions (they are without optimizer), but with Spring 3.1 - it doesn't
help. As more and more containers are switching to OSGi (or other similar
component isolation models) you can expect Cocoon to fail on more and more
containers...
Jetty 6 is so ancient already that pointing to it for new developments is just
irrelevant... It works there only by accident. You can claim that AspectJ is
the problem, but they declared it clearly that they will not fix it, at leas
soon, as this requires serious redesign of its optimizer.
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175984#comment-13175984
]
Francesco Chicchiriccò commented on COCOON3-85:
---
I have committed today some version updates in C3 sources (including Spring
3.1).
I have forked your GitHub project at
git://github.com/ilgrosso/cocoon-springification.git
You can test my fork by:
# git clone git://github.com/ilgrosso/cocoon-springification.git
# cd cocoon-springification
# mvn clean install
# cd webapp
At this point you can choose which JEE container to run with:
# mvn -P cargo.jetty6x
or
# mvn -P cargo.tomcat7x
or
# mvn -P cargo.jetty7x
or
# mvn -P cargo.jetty8x
Without applying your patch, Jetty 6 and Tomcat 7 run fine, Jetty 7 and Jetty 8
fail with stacktrace you reported above, so I think this is more a Jetty (7 and
8) issue than C3's.
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
uncher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175747#comment-13175747
]
Igor Malinin commented on COCOON3-85:
-
Hmm... Probably this is because I am using AspectJ 1.6.6 (newer versions break
Cocoon on Jetty7+ because of ServletContextFactoryBean is not synthetic).
I'll try to get a stack trace for this and update my sample app so that you can
reproduce it.
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175746#comment-13175746
]
Francesco Chicchiriccò commented on COCOON3-85:
---
What is your use case? I've just tried to replace
3.0.7.RELEASE
with
3.1.0.RELEASE
in parent/pom.xml, then launched it.sh and all went fine.
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Malinin updated COCOON3-85:
Attachment: java.patch
Spring 3.1 support, assumes at least Spring 3.0
> cocoon-spring-configurator doesn't work with Spring 3.1
> ---
>
> Key: COCOON3-85
> URL: https://issues.apache.org/jira/browse/COCOON3-85
> Project: Cocoon 3
> Issue Type: Bug
> Components: cocoon-servlet
>Affects Versions: 3.0.0-beta-1
>Reporter: Igor Malinin
>Priority: Critical
> Attachments: java.patch
>
>
> There are several issues that prevent Cocoon 3 to work with Spring 3.1
> One issue I reported already in mailing list when Jetty7 + recent AspectJ was
> failing, not the same issue is deeper and ServletContextFactoryBean doesn't
> work at all with Spring 3.1.
> Note that ServletContext is already in the Spring web-app context, although
> with another name ('servletContext'). This is available starting from Spring
> 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext'
> solves problem partially, but still fails on XMLSitemapServlet initialization
> (as it uses static field in ServletContextFactoryBean).
> I will attach a patch (a little bit dirty, but not more than the current
> implementation). But it assumes at least Spring 3.0.
> As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
> as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
> etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
cocoon-spring-configurator doesn't work with Spring 3.1
---
Key: COCOON3-85
URL: https://issues.apache.org/jira/browse/COCOON3-85
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-servlet
Affects Versions: 3.0.0-beta-1
Reporter: Igor Malinin
Priority: Critical
Attachments: java.patch
There are several issues that prevent Cocoon 3 to work with Spring 3.1
One issue I reported already in mailing list when Jetty7 + recent AspectJ was
failing, not the same issue is deeper and ServletContextFactoryBean doesn't
work at all with Spring 3.1.
Note that ServletContext is already in the Spring web-app context, although
with another name ('servletContext'). This is available starting from Spring
3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext' solves
problem partially, but still fails on XMLSitemapServlet initialization (as it
uses static field in ServletContextFactoryBean).
I will attach a patch (a little bit dirty, but not more than the current
implementation). But it assumes at least Spring 3.0.
As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have as
a dependency at leas 3.0 version of Spring Framework (for Java5 generics etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [C3] Cocoon Spring Configurator, sitemap reload and exception unroll
On 29/06/2011 00:34, Reinhard Pötz wrote: On 06/28/2011 10:29 AM, Francesco Chicchiriccò wrote: Gents, Cocoon 3 is using Cocoon Spring Configurator 2.1[1]; by default this is triggered by an empty in main applicationContext.xml. In my project I need to: 1. always reload sitemap.xmap from the filesystem during development Am I right that you use C3 within a Wicket application and can't use the "default" reloading classloader stuff based on the Cocoon Maven Plugin (mvn cocoon:prepare)? Actually not: I gave up in using the cocoon-sample-wicket-webapp as a base for my application because of the missing "servlet:/" feature. I need the reloading feature that a block has (thanks to the Cocoon Maven Plugin) but I also want to build a webapp that can be overlayed. If I understood well, the cocoon-sample / cocoon-sample-webapp pair does not meet these needs barely because the cocoon-sample-webapp is an empty shell for cocoon-sample. Hence, if you overlay a WAR produced by cocoon-sample-webapp, you can't handle into the sitemap stuff. This is the reason why I am building my project (a Cocoon3-based framework for delivering content managed by the enterprise Hippo CMS - http://forge.onehippo.org/gf/project/hct/) as a maven WAR artifact with more or less the same "developer-friendly" features that a block has. Basically, my META-INF/cocoon/spring/servlet-service.xml declares the XMLSitemapServlet as the following: 2. catch the real cause of a ProcessingException (I was inspired by [2]) yes, makes sense. Hence I set something like as Then, I modified [3] and [4] in order to handle this kind of configuration: the patch is attached to this e-mail. Do you think this could be useful in general? If so I would commit gladly. If my "C3 within Wicket" assumption is right, I'm fine with your suggestions. What do you think, then? Thanks. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Cocoon Spring Configurator, sitemap reload and exception unroll
On 06/28/2011 10:29 AM, Francesco Chicchiriccò wrote: Gents, Cocoon 3 is using Cocoon Spring Configurator 2.1[1]; by default this is triggered by an empty in main applicationContext.xml. In my project I need to: 1. always reload sitemap.xmap from the filesystem during development Am I right that you use C3 within a Wicket application and can't use the "default" reloading classloader stuff based on the Cocoon Maven Plugin (mvn cocoon:prepare)? 2. catch the real cause of a ProcessingException (I was inspired by [2]) yes, makes sense. Hence I set something like as Then, I modified [3] and [4] in order to handle this kind of configuration: the patch is attached to this e-mail. Do you think this could be useful in general? If so I would commit gladly. If my "C3 within Wicket" assumption is right, I'm fine with your suggestions. -- Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[C3] Cocoon Spring Configurator, sitemap reload and exception unroll
Gents,
Cocoon 3 is using Cocoon Spring Configurator 2.1[1]; by default this is
triggered by an empty
in main applicationContext.xml.
In my project I need to:
1. always reload sitemap.xmap from the filesystem during development
2. catch the real cause of a ProcessingException (I was inspired by [2])
Hence I set something like as
value="true"/>
name="org.apache.cocoon.exception.ProcessingException.unroll" value="true"/>
Then, I modified [3] and [4] in order to handle this kind of
configuration: the patch is attached to this e-mail.
Do you think this could be useful in general? If so I would commit gladly.
Cheers.
[1]
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/2.1/1304_1_1.html
[2] http://cocoon.apache.org/2.2/core-modules/core/2.2/1379_1_1.html
[3]
cocoon-servlet/src/main/java/org/apache/cocoon/servlet/XMLSitemapServlet.java
[4]
cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
Index: cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java
===
--- cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java (revisione 1140447)
+++ cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java (copia locale)
@@ -27,6 +27,7 @@
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
+import org.apache.cocoon.configuration.Settings;
import org.apache.cocoon.pipeline.Pipeline;
import org.apache.cocoon.pipeline.component.Finisher;
@@ -38,6 +39,7 @@
import org.apache.cocoon.sitemap.util.ParameterHelper;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.springframework.beans.factory.annotation.Autowired;
public class InvocationImpl implements Invocation {
@@ -62,6 +64,9 @@
private ObjectModel objectModel;
private boolean hasFinisher;
+
+@Autowired
+private Settings settings;
public InvocationImpl() {
}
@@ -319,7 +324,17 @@
*/
public void setThrowable(final Throwable throwable) {
Throwable cause = ExceptionHandler.getCause(throwable);
-
+if (null != cause) {
+final String unroll =
+settings.getProperty("org.apache.cocoon.exception."
++ cause.getClass().getSimpleName() + ".unroll");
+if (unroll != null && "true".equalsIgnoreCase(unroll)) {
+while (cause.getCause() != null) {
+cause = cause.getCause();
+}
+}
+}
+
this.objectModel.getCocoonObject().put("exception", cause);
ParameterHelper.setThrowable(this.parameters, cause);
Index: cocoon-servlet/src/main/java/org/apache/cocoon/servlet/XMLSitemapServlet.java
===
--- cocoon-servlet/src/main/java/org/apache/cocoon/servlet/XMLSitemapServlet.java (revisione 1140447)
+++ cocoon-servlet/src/main/java/org/apache/cocoon/servlet/XMLSitemapServlet.java (copia locale)
@@ -24,6 +24,7 @@
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.cocoon.configuration.Settings;
import org.apache.cocoon.spring.configurator.WebAppContextUtils;
import org.apache.commons.logging.Log;
@@ -57,7 +58,11 @@
throws ServletException {
synchronized (this) {
-if (this.requestProcessor != null) {
+final Settings settings = (Settings) WebAppContextUtils.
+getCurrentWebApplicationContext().getBean(
+Settings.class.getName());
+if (!settings.isReloadingEnabled("sitemap")
+&& this.requestProcessor != null) {
return;
}
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Benjamin Boksa wrote:
Not sure if I understand you on that one… Let's assume there are two
"foo.properties" files both containing a property "bar" - when using the
settings above how does the spring-configurator decide which is the
right property to use? I think this might result in a problem (the wrong
"bar"-property is used)…
you are of course right :) I was talking about the opposite:
file1.jar: application.properties with 'foo' property
file2.jar: application.properties with 'bar' property
classpath:/META-INF/properties/application.properties will pick one file
(which one is either not deterministic or depends on jar file naming).
classpath*:/META-INF/properties/application.properties will pick both
files and load all properties. This way you do not have to keep
different names across modules.
However the big problem/misunderstanding/bug is that with my the
original settings
dir="META-INF/foo-service/properties"/>
the bean definitions seem to be read correctly while the properties are
not - which I absolutely can't understand. I feel a bit like going in
circles and can't find any good resources (despite of Leszek ;-) ) which
might help me solve this problem.
I am afraid this is simply a false positive. In other words: a pure
coincidence.
So if you have further information please let me know :-)
Your path definition: META-INF/foo-service/properties gets converted into:
classpath:META-INF/foo-service/properties/*.properties
which is an 'ant style path'. [1] states:
Ant-style patterns with "classpath:" resources are not guaranteed to
find matching resources if the root package to search is available in
multiple class path locations. This is because a resource such as
com/mycompany/package1/service-context.xml
may be in only one location, but when a path such as
classpath:com/mycompany/**/service-context.xml
is used to try to resolve it, the resolver will work off the (first) URL
returned by getResource("com/mycompany");. If this base package node
exists in multiple classloader locations, the actual end resource may
not be underneath. Therefore, preferably, use "classpath*:" with the
same Ant-style pattern in such a case, which will search all class path
locations that contain the root package.
Have fun
[1]
http://static.springframework.org/spring/docs/2.5.x/reference/resources.html#resources-wildcards-in-path-other-stuff
[2]
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Am 12.02.2009 um 14:29 schrieb Leszek Gawron: Benjamin Boksa wrote: Hi Leszek, thanks you very much for looking into my problem: I have run your test scenario. Please use the following statement: using classpath*: ensures that spring will scan all available jars for that path and aggregate the results. That (scanning all jars) actually was one of the things I tried to avoid (as this might cause problems with the same directories existing in two jars). Not very likely, I know, but avoidable as the configurator test-case shows. One more comment: there is completely no problem if every jar has / META-INF/properties/application.properties file. Every file has unique URL and the property placeholder will pick all of them. Treat it more like a nice feature than a problem :) Not sure if I understand you on that one… Let's assume there are two "foo.properties" files both containing a property "bar" - when using the settings above how does the spring-configurator decide which is the right property to use? I think this might result in a problem (the wrong "bar"-property is used)… However the big problem/misunderstanding/bug is that with my the original settings the bean definitions seem to be read correctly while the properties are not - which I absolutely can't understand. I feel a bit like going in circles and can't find any good resources (despite of Leszek ;-) ) which might help me solve this problem. So if you have further information please let me know :-) Thanks for you time Benjamin
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Benjamin Boksa wrote: Hi Leszek, thanks you very much for looking into my problem: I have run your test scenario. Please use the following statement: dir="classpath*:/META-INF/foo-service/spring"/> dir="classpath*:/META-INF/foo-service/properties"/> using classpath*: ensures that spring will scan all available jars for that path and aggregate the results. That (scanning all jars) actually was one of the things I tried to avoid (as this might cause problems with the same directories existing in two jars). Not very likely, I know, but avoidable as the configurator test-case shows. One more comment: there is completely no problem if every jar has /META-INF/properties/application.properties file. Every file has unique URL and the property placeholder will pick all of them. Treat it more like a nice feature than a problem :) -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Benjamin Boksa wrote: Is there any recommended dependeny/dependency-exclusion setup to make cocoon-core utilize the new (2.0.0) spring-configurator? I have tried several dependency-configurations but was not able to find a working one. I would be really glad for any help on that point - as you can image I am quite clueless at the moment. Probably the easiest thing to do now is to go for cocoon trunk. Usually for cocoon this is not as bad as it may seem. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Hi Leszek, thanks you very much for looking into my problem: I have run your test scenario. Please use the following statement: using classpath*: ensures that spring will scan all available jars for that path and aggregate the results. That (scanning all jars) actually was one of the things I tried to avoid (as this might cause problems with the same directories existing in two jars). Not very likely, I know, but avoidable as the configurator test-case shows. Nevertheless I applied your changes and ran into the same problem: Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'foo.test.service': Invocation of init method failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.apache.excalibur.source.SourceResolver' is defined After doing some further investigations on that point I found out (mvn dependency:tree) the cocoon-core 2.2.0 still uses the (old) 1.0.2 configurator which does not seem to support the include-properties setting (I could not find any documentation on that point and I do not know how to get the sources of the 1.0.2 artifact :-( ). Is there any recommended dependeny/dependency-exclusion setup to make cocoon-core utilize the new (2.0.0) spring-configurator? I have tried several dependency-configurations but was not able to find a working one. I would be really glad for any help on that point - as you can image I am quite clueless at the moment. Thanks in advance for any information Benjamin
Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Benjamin Boksa wrote:
Hi List,
attached is a reproducible error I get when using the Cocoon Spring
Configurator 2.0 in "stand-alone" mode. The idea is to use the
configurator to implement a kind of ServiceLocator which internally uses
Spring and hides away the implementation details from the user (let me
know if this is completely bullshit…). It uses its own configuration
directories (META-INF/foo-service/{spring,properties}) to not get any
conflicts with "standard" cocoon locations.
Nevertheless here is the procedure to reproduce the error that drives me
mad:
1. Expand the attached file and change to the "configurator-test"-directory
2. run "mvn test" (you will see that two Strings ("Hello" and "Har Har")
are printed, where "Har Har" is configured using a PropertyPlaceholder -
this is the expected behaviour)
3. run "mvn install" to install the configurator-test artifact to you
local repository (don't forget to delete it later)
4. change to the test directory (cd ../test)
5. run mvn jetty:run
6. Open you browser and go to http://localhost:/test/spring-bean
7. BOOOM! You will see a "BeanDefinitionStoreException: Could not
resolve placeholder 'test.text'" - which works fine in step 2
This leads me to the assumption that
/META-INF/foo-service/spring/foo.xml from configurator-test is read
correctly but the Spring Configurator somehow fails to read
/META-INF/foo-service/properties/foo.properties…
If you need further information let me know about it - if I did
something wrong please let me know. I would be glad if you could
actually help me to fix this error as I can't imagine another solution
for my problem.
Please help me and let me know if I should file a bug report. Thanks in
advance
I have run your test scenario. Please use the following statement:
using classpath*: ensures that spring will scan all available jars for
that path and aggregate the results.
Your custom spring context gets properly initialized now but there is
another error that shows your block is somehow invalid:
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'foo.test.service': Invocation of init
method failed; nested exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'org.apache.excalibur.source.SourceResolver' is defined
I can't help you with that: I am still not using blocks in my project.
Hope that helps.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
[jira] Closed: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
[ https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2226. Resolution: Fixed Fixed in r678281. Thanks Abel for spotting my obvious mistake here. > Build error due to wrong dependency version from cocoon-servlet-service in > cocoon-spring-configurator > - > > Key: COCOON-2226 > URL: https://issues.apache.org/jira/browse/COCOON-2226 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Abel Muiño >Assignee: Grzegorz Kossakowski > Attachments: patch.txt > > > The pom for cocoon-servlet-service depends on > > org.apache.cocoon > cocoon-spring-configurator > 1.0.3-SNAPSHOT > compile > > (see > http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) > But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes > an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
[ https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2226: Assignee: Grzegorz Kossakowski > Build error due to wrong dependency version from cocoon-servlet-service in > cocoon-spring-configurator > - > > Key: COCOON-2226 > URL: https://issues.apache.org/jira/browse/COCOON-2226 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Abel Muiño >Assignee: Grzegorz Kossakowski > Attachments: patch.txt > > > The pom for cocoon-servlet-service depends on > > org.apache.cocoon > cocoon-spring-configurator > 1.0.3-SNAPSHOT > compile > > (see > http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) > But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes > an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
[ https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Muiño updated COCOON-2226: --- Attachment: patch.txt Changes version of dependency to 1.1.0-SNAPSHOT > Build error due to wrong dependency version from cocoon-servlet-service in > cocoon-spring-configurator > - > > Key: COCOON-2226 > URL: https://issues.apache.org/jira/browse/COCOON-2226 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Abel Muiño > Attachments: patch.txt > > > The pom for cocoon-servlet-service depends on > > org.apache.cocoon > cocoon-spring-configurator > 1.0.3-SNAPSHOT > compile > > (see > http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) > But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes > an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator - Key: COCOON-2226 URL: https://issues.apache.org/jira/browse/COCOON-2226 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Abel Muiño The pom for cocoon-servlet-service depends on org.apache.cocoon cocoon-spring-configurator 1.0.3-SNAPSHOT compile (see http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2160) Wrong element structure in schema file for cocoon-spring-configurator
Wrong element structure in schema file for cocoon-spring-configurator - Key: COCOON-2160 URL: https://issues.apache.org/jira/browse/COCOON-2160 Project: Cocoon Issue Type: Bug Components: Blocks: (Undefined) Reporter: Grzegorz Kossakowski Priority: Minor Schema located at http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd allows to put element as top-level which results in following exception: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionParser for element [include-beans] Closer look at schema reveals that element is supposed to be child of . Schema file must be restructured a little bit in order to avoid ambiguity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1995) Can't mount sitemap from using resource:// - cocoon-spring-configurator/avalon bridge doesn't support SourceResolver sources
[ https://issues.apache.org/jira/browse/COCOON-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1995: - Urgency: Low Fix Version/s: (was: 2.2-dev (Current SVN)) I set Fix version to none because there is no fix available at the moment and I don't consider this issue as blocker for Cocoon 2.2 release. > Can't mount sitemap from using resource:// - > cocoon-spring-configurator/avalon bridge doesn't support SourceResolver > sources > > > Key: COCOON-1995 > URL: https://issues.apache.org/jira/browse/COCOON-1995 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, - Components: Avalon >Affects Versions: 2.2-dev (Current SVN) >Reporter: Bart Molenkamp > > It isn't possible to just mount sitemaps from locations other than file:// > and http://, because the cocoon-spring-configurator/avalon bridge doesn't > support loading resources from the SourceResolver. Mounting a sitemap using > resource:// protocol throws the following exception (trying to mount the > sitemap resource://test.xmap): > org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap > at - > file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:12:83 > at - > file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:11:33 > at - > file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:17:80 > at - > file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:16:31 > at - > file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:6:30 > at - > file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:164:67 > at - > file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:163:28 > at > org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:111) > at > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) > at > org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) > at > org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) > at > org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) > at > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:233) > at > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) > at > org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) > at > org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) > at > org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreePr
Re: Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
Hi,
Thank you Daniel for your support and deep explanation.
I have chosen the second solution because i don´t like a weblogic specific
code. I attach the resulting code DeploymentUtil class.
Because of Weblogic is a very popular application server, I think this error
would be consider a bug and IMHO a patch should go in future cocoon
releases.
BR,
Juanjo
On 9/30/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
>
> Juanjo Vázquez skrev:
> > Hi all,
> >
> > I´m working in an Cocoon 2.2-RC1 web application with one block.
> > Everything is ok when i deploy to Tomcat but i´m getting errors when i
> > deploy to Weblogic 9.2. I have been looking for a workaround or a
> > solution and it seems the problem is the blocks are not deployed to the
> > public web directory in the weblogic domain.
> >
> > Everything points to the method "deployBlockResources" in
> > "DeploymentUtil" class (cocoon-spring-configuratior-1.0.0.jar) is not
> > working properly in this environment. I have been debugging the
> > application deployed to weblogic with these discoveries:
> >
> > 1. Spring loads the jar configurations with zip protocol instead jar
> > protocol, i.e.
> >
> zip:C:/bea/user_projects/domains/cm_domain/servers/AdminServer/tmp/_WL_user/proxy-ear/53xotj/war/WEB-INF/lib/cocoon-
> servlet-service-impl-1.0.0-M2.jar!/META-INF/cocoon/spring/cocoon-callstack-environment.xml
> >
> >
> > 2. In Runtime, the "URLConnection" class is a
> > "weblogic.utils.ZipUrlConnection" not a "JarURLConnection"
> >
> > Can anybody help me with this problem?
>
> Some background:
>
> Blocks can contain resources that are intended to be available in e.g.
> sitemaps. These resources are put in a directory called COB-INF at the
> root of the directory structure of a block. The blocks are ordinary jars
> that are put in WEB-INF/lib (during development the blocks can expanded
> also).
>
> The task of DeploymentUtil.deployBlockResources is to search the class
> path for all urls to COB-INF resources. If the url is of the type file:
> the url and the block name is registred. Then the resources in the
> COB-INF directory of the block is available through the blockcontext:
> source. If the url is a jar, the resources in the COB-INF directory are
> extracted to a temp directory in the file system and the url of the
> extracted resources is registred together with the clock name.
>
> For Weblogic it seem like the classloader contains zip: urls for
> resources. A solution would be to extend the
> DeploymentUtil.deployBlockResources method with a case for the zip:
> protocol, it would be similar to the jar: case but a little bit more
> compliacted as the zip protocol doesn't know about mainfest attributes.
> A problem with this is that the ZipUrlConnection is Weblogic specific,
> so the protocol handling code in deployBlockResources would need to be
> extracted to some components.
>
> Another, and much simpler solution if it works, would be to just replace
> "zip:" with "jar:" in the url string, create a new url object from the
> patched url string, and use the existing jar handling code.
>
> /Daniel
>
>
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.cocoon.spring.configurator.impl;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
import java.util.jar.JarFile;
import java.util.zip.ZipEntry;
import org.apache.commons.io.IOUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Helper class for deploying resources from the block artifacts.
*
* @version $Id: DeploymentUtil.java 555608 2007-07-12 12:12:54Z felixk $
* @since 1.0
*/
public abstract class DeploymentUtil {
protected static final Log logger = LogFactory.getLog(DeploymentUtil.class);
protected static final String BLOCK_RESOURCES_PATH = "COB-INF";
/**
* Deploy all files with a given prefix from a jar file to a directory
* in the file system.
* @param jarFile The jar file containing the resources.
* @param prefix The common pref
Re: Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
Juanjo Vázquez skrev: Hi all, I´m working in an Cocoon 2.2-RC1 web application with one block. Everything is ok when i deploy to Tomcat but i´m getting errors when i deploy to Weblogic 9.2. I have been looking for a workaround or a solution and it seems the problem is the blocks are not deployed to the public web directory in the weblogic domain. Everything points to the method "deployBlockResources" in "DeploymentUtil" class (cocoon-spring-configuratior-1.0.0.jar) is not working properly in this environment. I have been debugging the application deployed to weblogic with these discoveries: 1. Spring loads the jar configurations with zip protocol instead jar protocol, i.e. zip:C:/bea/user_projects/domains/cm_domain/servers/AdminServer/tmp/_WL_user/proxy-ear/53xotj/war/WEB-INF/lib/cocoon-servlet-service-impl-1.0.0-M2.jar!/META-INF/cocoon/spring/cocoon-callstack-environment.xml 2. In Runtime, the "URLConnection" class is a "weblogic.utils.ZipUrlConnection" not a "JarURLConnection" Can anybody help me with this problem? Some background: Blocks can contain resources that are intended to be available in e.g. sitemaps. These resources are put in a directory called COB-INF at the root of the directory structure of a block. The blocks are ordinary jars that are put in WEB-INF/lib (during development the blocks can expanded also). The task of DeploymentUtil.deployBlockResources is to search the class path for all urls to COB-INF resources. If the url is of the type file: the url and the block name is registred. Then the resources in the COB-INF directory of the block is available through the blockcontext: source. If the url is a jar, the resources in the COB-INF directory are extracted to a temp directory in the file system and the url of the extracted resources is registred together with the clock name. For Weblogic it seem like the classloader contains zip: urls for resources. A solution would be to extend the DeploymentUtil.deployBlockResources method with a case for the zip: protocol, it would be similar to the jar: case but a little bit more compliacted as the zip protocol doesn't know about mainfest attributes. A problem with this is that the ZipUrlConnection is Weblogic specific, so the protocol handling code in deployBlockResources would need to be extracted to some components. Another, and much simpler solution if it works, would be to just replace "zip:" with "jar:" in the url string, create a new url object from the patched url string, and use the existing jar handling code. /Daniel
Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
Hi all, I´m working in an Cocoon 2.2-RC1 web application with one block. Everything is ok when i deploy to Tomcat but i´m getting errors when i deploy to Weblogic 9.2. I have been looking for a workaround or a solution and it seems the problem is the blocks are not deployed to the public web directory in the weblogic domain. Everything points to the method "deployBlockResources" in "DeploymentUtil" class (cocoon-spring-configuratior-1.0.0.jar) is not working properly in this environment. I have been debugging the application deployed to weblogic with these discoveries: 1. Spring loads the jar configurations with zip protocol instead jar protocol, i.e. zip:C:/bea/user_projects/domains/cm_domain/servers/AdminServer/tmp/_WL_user/proxy-ear/53xotj/war/WEB-INF/lib/cocoon- servlet-service-impl-1.0.0-M2.jar!/META-INF/cocoon/spring/cocoon-callstack-environment.xml 2. In Runtime, the "URLConnection" class is a " weblogic.utils.ZipUrlConnection" not a "JarURLConnection" Can anybody help me with this problem? Thanks in advance. Juanjo.
Re: Cocoon Spring configurator
Reinhard Poetz wrote: > Carsten Ziegeler wrote: >>> /META-INF/cocoon/spring when using Cocoon Spring configurator >>> independently from >>> Cocoon. It's probably not that hard to change but we should do it before >>> propagating it :) >> There are constants defined in >> org.apache.cocoon.spring.configurator.impl.Constants. >> >> So changing this is very simple. The whole loading is done through own >> xml elements (the "settings" element). Most classes in >> org.apache.cocoon.spring.configurator.impl deals with this stuff. > > That means that we can make this a configuration option of the settings > element and its default value is "META-INF/cocoon/spring", right? The best thing is that we already have this :) you can embed "include-beans" and "include-properties" in the settings element which allow you to read the configuration from additional locations. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild1.apache.org/continuum/buildResult.action?buildId=1494&projectId=99 Build statistics: State: Error Previous State: Error Started at: Sun 19 Aug 2007 13:04:02 -0700 Finished at: Sun 19 Aug 2007 13:04:04 -0700 Total time: 1s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.4.2_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator' svn: PROPFIND of '/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator': could not connect to server (http://svn.apache.org) ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild1.apache.org/continuum/buildResult.action?buildId=1403&projectId=99 Build statistics: State: Error Previous State: Ok Started at: Sun 19 Aug 2007 12:10:40 -0700 Finished at: Sun 19 Aug 2007 12:10:42 -0700 Total time: 2s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.4.2_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator' svn: PROPFIND of '/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator': could not connect to server (http://svn.apache.org) ---
Re: Cocoon Spring configurator
On 19.08.2007 11:56 Uhr, Reinhard Poetz wrote: /META-INF/cocoon/spring when using Cocoon Spring configurator independently from Cocoon. It's probably not that hard to change but we should do it before propagating it :) There are constants defined in org.apache.cocoon.spring.configurator.impl.Constants. So changing this is very simple. The whole loading is done through own xml elements (the "settings" element). Most classes in org.apache.cocoon.spring.configurator.impl deals with this stuff. That means that we can make this a configuration option of the settings element and its default value is "META-INF/cocoon/spring", right? That's what I understood. Joerg
Re: Cocoon Spring configurator
Carsten Ziegeler wrote:
/META-INF/cocoon/spring when using Cocoon Spring configurator independently from
Cocoon. It's probably not that hard to change but we should do it before
propagating it :)
There are constants defined in
org.apache.cocoon.spring.configurator.impl.Constants.
So changing this is very simple. The whole loading is done through own
xml elements (the "settings" element). Most classes in
org.apache.cocoon.spring.configurator.impl deals with this stuff.
That means that we can make this a configuration option of the settings element
and its default value is "META-INF/cocoon/spring", right?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[continuum] BUILD SUCCESSFUL: Cocoon Spring Configurator
Online report :
http://vmbuild1.apache.org/continuum/buildResult.action?buildId=958&projectId=99
Build statistics:
State: Ok
Previous Build: No previous build.
Started at: Fri 17 Aug 2007 13:19:43 -0700
Finished at: Fri 17 Aug 2007 13:19:53 -0700
Total time: 10s
Build Trigger: Schedule
Build Number: 1
Exit code: 0
Building machine hostname: vmbuild
Operating system : Linux(unknown)
Java Home version :
java version "1.4.2_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
Builder version :
Maven version: 2.0.7
Java version: 1.4.2_15
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
No files changed
Dependencies Changes:
No dependencies changed
Test Summary:
Tests: 0
Failures: 0
Total time: 0
Output:
[INFO] Scanning for projects...
[INFO]
--------
[INFO] Building Cocoon Spring Configurator
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/99/target
[INFO] Deleting directory
/home/continuum/data/working-directory/99/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/99/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/99/target/site
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 22 source files to
/home/continuum/data/working-directory/99/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
/home/continuum/data/working-directory/99/target/cocoon-spring-configurator-1.0.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/continuum/data/working-directory/99/target/cocoon-spring-configurator-1.0.1-SNAPSHOT.jar
to
/home/continuum/.m2/repository/org/apache/cocoon/cocoon-spring-configurator/1.0.1-SNAPSHOT/cocoon-spring-configurator-1.0.1-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 8 seconds
[INFO] Finished at: Fri Aug 17 13:19:53 PDT 2007
[INFO] Final Memory: 11M/20M
[INFO]
Re: Cocoon Spring configurator
Joerg Heinicke wrote: > Carsten Ziegeler apache.org> writes: > > Carsten, when I recommended the bean map today [1] I wondered how it actually > works. The documentation talks about jar drop-in [2] which does not seem to be > the full truth. Please correct me if I'm wrong ... :) > > The BeanMap looks for all beans of a particular type. Therefore the beans > needs > to be registered in the application context. Yes, that's true - so you can use the bean map "standalone" without using anything else from the configurator. > So far so good, but here I think > the drop-in fails. Even if the jar includes the configuration the bean does > not > get added automatically to the application context. Only the other parts of > Cocoon Spring configurator enable this functionality. (If that's correct this > should better be added to the BeanMap documentation.) Yes, that's true - the bean map is just a map of some registered beans. Together with the other functionality of the spring configurator you get the automatic configuration stuff - and if such a configuration contains beans for the map, they are added to the map of course. Yepp, I think this needs some clarifications in the docs. > Which class exactly does > this? And how much stuff is hard-coded in it? You don't want to have paths > like > /META-INF/cocoon/spring when using Cocoon Spring configurator independently > from > Cocoon. It's probably not that hard to change but we should do it before > propagating it :) There are constants defined in org.apache.cocoon.spring.configurator.impl.Constants. So changing this is very simple. The whole loading is done through own xml elements (the "settings" element). Most classes in org.apache.cocoon.spring.configurator.impl deals with this stuff. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Cocoon Spring configurator
Carsten Ziegeler apache.org> writes: > Ah, great, yes bean map has been added later - I'll document it in the > next days. Carsten, when I recommended the bean map today [1] I wondered how it actually works. The documentation talks about jar drop-in [2] which does not seem to be the full truth. Please correct me if I'm wrong ... The BeanMap looks for all beans of a particular type. Therefore the beans needs to be registered in the application context. So far so good, but here I think the drop-in fails. Even if the jar includes the configuration the bean does not get added automatically to the application context. Only the other parts of Cocoon Spring configurator enable this functionality. (If that's correct this should better be added to the BeanMap documentation.) Which class exactly does this? And how much stuff is hard-coded in it? You don't want to have paths like /META-INF/cocoon/spring when using Cocoon Spring configurator independently from Cocoon. It's probably not that hard to change but we should do it before propagating it :) Regards, Joerg [1] http://forum.springframework.org/showthread.php?t=42701 [2] http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1400.html
Re: svn commit: r555496 - /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
On 12.07.2007 08:20, Felix Knecht wrote: Joerg Heinicke schrieb: My conclusion must be: NEVER getting up, committing the dreams I had during sleep and then getting fully awake ... Oh, you dream of unclosed streams? :-) Joerg
Re: svn commit: r555496 - /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
Joerg Heinicke schrieb: My conclusion must be: NEVER getting up, committing the dreams I had during sleep and then getting fully awake ... > Hi Felix, > > the streams are now closed twice since close() is also inside try > block. Also if outStream.close() fails with an exception instream will > remain open. > > Joerg >
Re: svn commit: r555496 - /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
Joerg Heinicke schrieb:
> On 12.07.2007 01:37, [EMAIL PROTECTED] wrote:
>> Author: felixk
>> Date: Wed Jul 11 22:37:32 2007
>> New Revision: 555496
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=555496
>> Log:
>> Make sure, they finally are closed
>
> Hi Felix,
>
> the streams are now closed twice since close() is also inside try
> block. Also if outStream.close() fails with an exception instream will
> remain open.
Ups, I forget to delete after copying.
Thanks Joerg
>
> Joerg
>
>> ==========
>>
>> ---
>> cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
>> (original)
>> +++
>> cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
>> Wed Jul 11 22:37:32 2007
>> @@ -67,11 +67,23 @@
>> final File out = new File(fileName);
>> // create directory
>> out.getParentFile().mkdirs();
>> -final InputStream inStream =
>> jarFile.getInputStream(entry);
>> -final OutputStream outStream = new
>> FileOutputStream(out);
>> -IOUtils.copy(inStream, outStream);
>> -inStream.close();
>> -outStream.close();
>> ++InputStream inStream = null;
>> +OutputStream outStream = null;
>> +try {
>> +inStream = jarFile.getInputStream(entry);
>> +outStream = new FileOutputStream(out);
>> +IOUtils.copy(inStream, outStream);
>> +inStream.close();
>> +outStream.close();
>> +} finally {
>> +if (outStream != null) {
>> +outStream.close();
>> +}
>> +if (inStream != null) {
>> +inStream.close();
>> +}
>> +}
>> }
>> }
>> }
>>
>>
>
Re: svn commit: r555496 - /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
On 12.07.2007 01:37, [EMAIL PROTECTED] wrote:
Author: felixk
Date: Wed Jul 11 22:37:32 2007
New Revision: 555496
URL: http://svn.apache.org/viewvc?view=rev&rev=555496
Log:
Make sure, they finally are closed
Hi Felix,
the streams are now closed twice since close() is also inside try block.
Also if outStream.close() fails with an exception instream will remain open.
Joerg
==
---
cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
(original)
+++
cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java
Wed Jul 11 22:37:32 2007
@@ -67,11 +67,23 @@
final File out = new File(fileName);
// create directory
out.getParentFile().mkdirs();
-final InputStream inStream = jarFile.getInputStream(entry);
-final OutputStream outStream = new FileOutputStream(out);
-IOUtils.copy(inStream, outStream);
-inStream.close();
-outStream.close();
+
+InputStream inStream = null;
+OutputStream outStream = null;
+try {
+inStream = jarFile.getInputStream(entry);
+outStream = new FileOutputStream(out);
+IOUtils.copy(inStream, outStream);
+inStream.close();
+outStream.close();
+} finally {
+if (outStream != null) {
+outStream.close();
+}
+if (inStream != null) {
+inStream.close();
+}
+}
}
}
}
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
Joerg Heinicke wrote: > On 22.05.2007 07:10, Giacomo Pati wrote: > >>> 1. Could you please provide links to the thread discussing applied >>> changes? It really helps to understand these changes 2 months later. >> >> Well, the changes are freshly discussed (not 2 month later). > > I guess it's meant the other way around: What's known in 2 months (or > thereafter) when somebody has a look on the code/commit message? It was a silly language mistake that did not show my intention. Thanks Joerg for explaining it. -- Grzegorz Kossakowski
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
On 22.05.2007 07:10, Giacomo Pati wrote: 1. Could you please provide links to the thread discussing applied changes? It really helps to understand these changes 2 months later. Well, the changes are freshly discussed (not 2 month later). I guess it's meant the other way around: What's known in 2 months (or thereafter) when somebody has a look on the code/commit message? Joerg
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > [EMAIL PROTECTED] pisze: >> Author: giacomo >> Date: Mon May 21 06:52:41 2007 >> New Revision: 540144 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=540144 >> Log: >> enhance the bean-map for service servlet use case > > Giacomo, thanks for implementing this. I have few comments: > 1. Could you please provide links to the thread discussing applied > changes? It really helps to understand these changes 2 months later. Well, the changes are freshly discussed (not 2 month later). The changes to the bean-map provider is the refactoring of the DispatcherServlet's logic collecting block servlets (as discussed in the recent thread about DispatcherServlet) > 2. If you modify schema don't forget to publish changes, otherwise > people's svn copies will break soon or later. (I've done it myself > already so don't bother yourself) Thanks. Didn't know they need to be published. > 3. Could you please add information about your changes to changes.xml file? I have not thought that change would have enough importance to be mentioned there! > I have updated the schema by moving your comments to xsd:documentation > elements. I hope you don't mind. Thanks alot, it's your code as well as mine ;-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGUnszLNdJvZjjVZARAgO1AJ9CH5NDDGalOgmWsdTIARAbeDXhTgCfdTrg W4JFPCM90nLKKeudmNeCnjE= =xPAU -END PGP SIGNATURE-
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
[EMAIL PROTECTED] pisze: Author: giacomo Date: Mon May 21 06:52:41 2007 New Revision: 540144 URL: http://svn.apache.org/viewvc?view=rev&rev=540144 Log: enhance the bean-map for service servlet use case Giacomo, thanks for implementing this. I have few comments: 1. Could you please provide links to the thread discussing applied changes? It really helps to understand these changes 2 months later. 2. If you modify schema don't forget to publish changes, otherwise people's svn copies will break soon or later. (I've done it myself already so don't bother yourself) 3. Could you please add information about your changes to changes.xml file? I have updated the schema by moving your comments to xsd:documentation elements. I hope you don't mind. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > [EMAIL PROTECTED] wrote: >> Author: giacomo >> Date: Mon May 21 06:52:41 2007 >> New Revision: 540144 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=540144 >> Log: >> enhance the bean-map for service servlet use case >> >> Added: >> >> cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.2.xsd >> >> (with props) > > Since we haven't released 1.0.1 so far, it's not necessary to increment > the version number. Ok, thanks. I've merged 1.0.2 into 1.0.1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGUcFELNdJvZjjVZARAvbwAJ48n2pU8f/YeK+QcpYwHLdrIthTcwCdGsiD o4m9tO/Rc+6fNsTDq2jkyA4= =8dm/ -END PGP SIGNATURE-
Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco
[EMAIL PROTECTED] wrote:
Author: giacomo
Date: Mon May 21 06:52:41 2007
New Revision: 540144
URL: http://svn.apache.org/viewvc?view=rev&rev=540144
Log:
enhance the bean-map for service servlet use case
Added:
cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.2.xsd
(with props)
Since we haven't released 1.0.1 so far, it's not necessary to increment the
version number.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: cocoon-spring-configurator in trunk not working?
Alexander Klimetschek wrote:
Hi all!
I want to use spring-2.0.3, but although all cocoon poms in trunk now
reference 2.0.3, the dependency to cocoon-spring-configurator in release
version 1.0.0 still pulls in 2.0.2, so effectively that older one is used.
Now I changed the dependency to cocoon-spring-configurator to
1.0.1-SNAPSHOT locally, so that I use the version in trunk. But I get
the error that the namespace handler for
http://cocoon.apache.org/schema/servlet (the servlet services bean
stuff) is not registered and Spring throws a NPE while parsing the
blockservlet.xml configurations.
Where do those namespaces are configured?
see
trunk\core\cocoon-servlet-service\cocoon-servlet-service-impl\src\main\resources\META-INF\spring.schemas
, org.apache.cocoon.servletservice.spring.ServletNamespaceHandler and
org.apache.cocoon.servletservice.spring.ServletDecorator
I could not find any
reference. And is spring-configurator in trunk somehow stable or are
there new developments in progress?
not that I know of. AFAIK we haven't changed much since the release.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
cocoon-spring-configurator in trunk not working?
Hi all! I want to use spring-2.0.3, but although all cocoon poms in trunk now reference 2.0.3, the dependency to cocoon-spring-configurator in release version 1.0.0 still pulls in 2.0.2, so effectively that older one is used. Now I changed the dependency to cocoon-spring-configurator to 1.0.1-SNAPSHOT locally, so that I use the version in trunk. But I get the error that the namespace handler for http://cocoon.apache.org/schema/servlet (the servlet services bean stuff) is not registered and Spring throws a NPE while parsing the blockservlet.xml configurations. Where do those namespaces are configured? I could not find any reference. And is spring-configurator in trunk somehow stable or are there new developments in progress? Alex -- Alexander Klimetschek http://www.mindquarry.com
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67162 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 23:01:10 -0800 Finished at: Thu, 1 Mar 2007 23:01:10 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67127 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 22:01:18 -0800 Finished at: Thu, 1 Mar 2007 22:01:18 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67091 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 21:01:12 -0800 Finished at: Thu, 1 Mar 2007 21:01:13 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67056 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 20:01:09 -0800 Finished at: Thu, 1 Mar 2007 20:01:10 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67021 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 19:01:07 -0800 Finished at: Thu, 1 Mar 2007 19:01:07 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/67002 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 18:00:52 -0800 Finished at: Thu, 1 Mar 2007 18:00:52 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66967 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 17:01:08 -0800 Finished at: Thu, 1 Mar 2007 17:01:08 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66932 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 16:01:03 -0800 Finished at: Thu, 1 Mar 2007 16:01:04 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66897 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 15:01:07 -0800 Finished at: Thu, 1 Mar 2007 15:01:07 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66862 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 14:01:06 -0800 Finished at: Thu, 1 Mar 2007 14:01:07 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66834 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 13:01:48 -0800 Finished at: Thu, 1 Mar 2007 13:01:49 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66797 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 12:01:21 -0800 Finished at: Thu, 1 Mar 2007 12:01:21 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66762 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 11:01:57 -0800 Finished at: Thu, 1 Mar 2007 11:01:58 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66725 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 10:03:13 -0800 Finished at: Thu, 1 Mar 2007 10:03:14 -0800 Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66690 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 09:01:32 -0800 Finished at: Thu, 1 Mar 2007 09:01:32 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66654 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 08:02:53 -0800 Finished at: Thu, 1 Mar 2007 08:02:54 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66616 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 07:03:37 -0800 Finished at: Thu, 1 Mar 2007 07:03:37 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66593 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 06:01:25 -0800 Finished at: Thu, 1 Mar 2007 06:01:26 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66571 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 05:03:31 -0800 Finished at: Thu, 1 Mar 2007 05:03:31 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66535 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 04:06:54 -0800 Finished at: Thu, 1 Mar 2007 04:06:54 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66499 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 03:06:00 -0800 Finished at: Thu, 1 Mar 2007 03:06:01 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66463 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 02:05:20 -0800 Finished at: Thu, 1 Mar 2007 02:05:20 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66425 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 01:06:06 -0800 Finished at: Thu, 1 Mar 2007 01:06:08 -0800 Total time: 2s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66389 Build statistics: State: Error Previous State: Error Started at: Thu, 1 Mar 2007 00:03:30 -0800 Finished at: Thu, 1 Mar 2007 00:03:31 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66344 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 23:01:21 -0800 Finished at: Wed, 28 Feb 2007 23:01:22 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66308 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 22:01:30 -0800 Finished at: Wed, 28 Feb 2007 22:01:31 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66264 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 21:01:29 -0800 Finished at: Wed, 28 Feb 2007 21:01:29 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66242 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 20:01:30 -0800 Finished at: Wed, 28 Feb 2007 20:01:31 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66206 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 19:01:45 -0800 Finished at: Wed, 28 Feb 2007 19:01:46 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66166 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 18:01:24 -0800 Finished at: Wed, 28 Feb 2007 18:01:24 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66130 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 17:01:23 -0800 Finished at: Wed, 28 Feb 2007 17:01:24 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66094 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 16:01:29 -0800 Finished at: Wed, 28 Feb 2007 16:01:30 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66058 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 15:01:28 -0800 Finished at: Wed, 28 Feb 2007 15:01:28 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
[continuum] BUILD ERROR: Cocoon Spring Configurator
Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/336/buildId/66018 Build statistics: State: Error Previous State: Error Started at: Wed, 28 Feb 2007 14:03:58 -0800 Finished at: Wed, 28 Feb 2007 14:03:58 -0800 Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-spring-configurator' doesn't exist ---
