Re: Ideas for student projects
Michael Wechner wrote:
Reinhard Poetz wrote:
Google announced the 3rd summer of code and this year. The Austrian
Computer society launched a similar project, the OSS Contest Austria
2007. We as Cocoon project can make proposals about possible student
projects.
If you have ideas for such projects, add them to
http://wiki.apache.org/cocoon/StudentProjectIdeas2007. The more ideas
we have, the better for us!
the link http://osscontest.ocg.at/ doesn't seem to work. And idea what
might be wrong?
works for me :-/
Does a DNS lookup on osscontest.ocg.at work for you?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Error building from trunk
Trying to build a new svn co from trunk. Does anybody else gets the same error? Regards Felix prompt MAVEN_OPTS=-Xmx256M mvn clean install -Dmaven.test.skip=true [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core-modules/3/cocoon-core-modules-3.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-core-modules Version: 3 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-core-modules:pom:3 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project: null:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project: null:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon-core-modules' not found in repository: Unable to download the artifact from any repository
Re: Error building from trunk
Seem like the cocoon-sitemap-impl and the cocoon-forms-impl POMs wasn't properly updated after the release. I just checked in a fix, so hopefully it works now. /Daniel Felix Knecht skrev: Trying to build a new svn co from trunk. Does anybody else gets the same error? Regards Felix prompt MAVEN_OPTS=-Xmx256M mvn clean install -Dmaven.test.skip=true [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core-modules/3/cocoon-core-modules-3.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-core-modules Version: 3 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-core-modules:pom:3 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project: null:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project: null:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon-core-modules' not found in repository: Unable to download the artifact from any repository
[SOLVED] Re: Error building from trunk
Daniel Fagerstrom schrieb: Seem like the cocoon-sitemap-impl and the cocoon-forms-impl POMs wasn't properly updated after the release. I just checked in a fix, so hopefully it works now. Thank you, it's working. Felix /Daniel Felix Knecht skrev: Trying to build a new svn co from trunk. Does anybody else gets the same error?
Re: [SOLVED] Re: Error building from trunk
Felix Knecht wrote:
Daniel Fagerstrom schrieb:
Seem like the cocoon-sitemap-impl and the cocoon-forms-impl POMs wasn't
properly updated after the release. I just checked in a fix, so
hopefully it works now.
Thank you, it's working.
Daniel Felix, thanks for spotting and fixing this. I had to release
cocoon-sitemap-impl again because of the missing sitemap schema and forgot to
commit change to snapshot versions.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[jira] Updated: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1987: - Attachment: authentication-fw.diff The patch you (Carsten) committed works well. Here's the patch I wrote recently about. For me both examples (non- and flowscript are working). From my pov this issue can be closed. Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at
[jira] Updated: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1987: - Other Info: [Patch available] Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) at
Re: Ideas for student projects
Reinhard Poetz wrote: Michael Wechner wrote: Reinhard Poetz wrote: Google announced the 3rd summer of code and this year. The Austrian Computer society launched a similar project, the OSS Contest Austria 2007. We as Cocoon project can make proposals about possible student projects. If you have ideas for such projects, add them to http://wiki.apache.org/cocoon/StudentProjectIdeas2007. The more ideas we have, the better for us! the link http://osscontest.ocg.at/ doesn't seem to work. And idea what might be wrong? works for me :-/ Does a DNS lookup on osscontest.ocg.at work for you? no, but www.ocg.at works fine Cheers Michael -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
JIRA karma
I'd like to close some JIRA issues, but I don't seem to have karma for doing that. The only workflow action I can see is Feedback required. Am I missing something? Otherwise I would appreciate if someone with enough power could upgrade my JIRA account, so that I can close issues. /Daniel
[jira] Commented: (COCOON-1997) Configure servlet: links rewriting
[ https://issues.apache.org/jira/browse/COCOON-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474022 ] Daniel Fagerstrom commented on COCOON-1997: --- Applied. Thanks for the patches! Configure servlet: links rewriting -- Key: COCOON-1997 URL: https://issues.apache.org/jira/browse/COCOON-1997 Project: Cocoon Issue Type: Sub-task Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski (aka g[R]eK) Fix For: 2.2-dev (Current SVN) Attachments: cocoon-servlet-service-components-linkrewriting-patch-2.txt, cocoon-servlet-service-impl-linkrewriting-transformer-patch-1.txt, cocoon-webapp-switch-to-servlet-service-patch-1.txt This issue is on configuring (or creating new) transformer that will take care of servlet: link rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1993) Make Forms resources loaded directly
[ https://issues.apache.org/jira/browse/COCOON-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474039 ] Daniel Fagerstrom commented on COCOON-1993: --- The new content and location of manifest.js seem to be lacking in the patch. Now it is only removed. Make Forms resources loaded directly Key: COCOON-1993 URL: https://issues.apache.org/jira/browse/COCOON-1993 Project: Cocoon Issue Type: Sub-task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski (aka g[R]eK) Fix For: 2.2-dev (Current SVN) Attachments: cocoon-forms-impl-patch-1.txt, cocoon-forms-impl-patch-2.txt, cocoon-forms-impl-patch-3.txt, cocoon-forms-sample-patch-1.txt, cocoon-forms-sample-patch-2.txt, cocoon-forms-sample-patch-3.txt Steps required to achieve this goal are the same as in https://issues.apache.org/jira/browse/COCOON-1992 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1993) Make Forms resources loaded directly
[ https://issues.apache.org/jira/browse/COCOON-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1993: - Attachment: cocoon-forms-impl-patch-4.txt cocoon-forms-impl-patch-4.txt: Grrr. Another bug in Subclipse found. When you move file and make additional modifications, only those modifications will be included in the patch. That makes applying patch broken. Now it should work. Make Forms resources loaded directly Key: COCOON-1993 URL: https://issues.apache.org/jira/browse/COCOON-1993 Project: Cocoon Issue Type: Sub-task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: cocoon-forms-impl-patch-1.txt, cocoon-forms-impl-patch-2.txt, cocoon-forms-impl-patch-3.txt, cocoon-forms-impl-patch-4.txt, cocoon-forms-sample-patch-1.txt, cocoon-forms-sample-patch-2.txt, cocoon-forms-sample-patch-3.txt Steps required to achieve this goal are the same as in https://issues.apache.org/jira/browse/COCOON-1992 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Improving ServletConnection to make it cache-aware
Alexander Klimetschek napisał(a): Grzegorz Kossakowski schrieb: While implementing this some questions arisen: 1. What about error handling? Should we provide some mechanism for passing exception from one servlet to the another? Or maybe just a error code and string message is sufficient? Since it is one stacktrace if you call an internal servlet backed up by a SitemapServlet, you can simply pass on the ProcessingException and not serializing an error page into the stream between both servlets. In the old blocks-fw-impl there is a patch that does exactly that, it re-throws the exception: https://issues.apache.org/jira/browse/COCOON-1954 It works fine for me. Thanks for the pointer. BTW: The following problems have been issues with the blocks-fw I have encountered during real-world usage, especially when using cforms in the backend-servlet. We should check those in the new implementation. https://issues.apache.org/jira/browse/COCOON-1964 https://issues.apache.org/jira/browse/COCOON-1939 My current priority is implementing postable sources and polishing patches that I've already provided. This could be added on the third position of my TODO list but I do not behave impolitely sweeping up all interesting work related to servlet services. Do you have any plans associated with these issues in foreseeable future? -- Grzegorz Kossakowski
[jira] Commented: (COCOON-1954) [Patch] RequestProcessor swallows exceptions in blocks case
[ https://issues.apache.org/jira/browse/COCOON-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474044 ] Grzegorz Kossakowski commented on COCOON-1954: -- It works fine for me. I think it can be closed. Alexander? Daniel? [Patch] RequestProcessor swallows exceptions in blocks case --- Key: COCOON-1954 URL: https://issues.apache.org/jira/browse/COCOON-1954 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-request-processor-swallows-exceptions-for-blocks.patch While updating to the latest Cocoon I stepped into the problem that you cannot see the exceptions thrown in a BlockServlet called by another one, since the new refactored RequestProcessor swallows all exceptions. The generated error page is fed into the response output stream which is eventually read by anything in the calling pipeline, which mostly cannot handle that html error page (in my case it gets some xml) and will throw another exception like SAXParseException. This patch adds a boolean rethrowExceptions() method to the RequestProcessor that is used inside service() to check whether a catched exception should be rethrown. The standard return value is false, in the subclass o.a.c.sitemap.SitemapServlet$RequestProcessor it returns true so that the exception is passed on to the root sitemap (handling the servletrequest that actually comes from a browser or so) which will eventually create the error page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2008) servletContext of BlockPathModule persists between seperate requests
[ https://issues.apache.org/jira/browse/COCOON-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474047 ] Grzegorz Kossakowski commented on COCOON-2008: -- I've tested your changes with refactored Forms (they use block-path module quite heavily) and everything works fine. Thanks. Close this issue, please. servletContext of BlockPathModule persists between seperate requests Key: COCOON-2008 URL: https://issues.apache.org/jira/browse/COCOON-2008 Project: Cocoon Issue Type: Bug Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: COCOON-2008-prototype-scope.txt, COCOON-2008.txt The same servlet context is being reused between _separate_ requests leading to returning invalid absolute uri's. It seems that this line: this.servletContext = CallStackHelper.getBaseServletContext(); is being called only once, when BlockPathModule is used first time, and then servletContext is never null (holds old value). I'm not sure, but it seems that life cycle of this class is not set up correctly. Even though I'm going to figure it out, it would be great if someone with better Spring/Cocoon internals knowledge could take a look on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2012) Catch Throwable, instead of Exception, in org.apache.cocoon.servlet.RequestProcessor
Catch Throwable, instead of Exception, in org.apache.cocoon.servlet.RequestProcessor Key: COCOON-2012 URL: https://issues.apache.org/jira/browse/COCOON-2012 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Rice Yeh There are many catch-all-exceptions handling in org.apache.cocoon.servlet.RequestProcessor, where 'catch (Exception e)' is used. Hence, Error will not be caught. For this catching-all-exceptions purpose handling code, it is better to use 'catch (Throwable t)' as stated in http://www.javaworld.com/javaworld/javaqa/2003-02/02-qa-0228-evilthrow.html. I am writing a RequestListener and expect this listener get called when any throwables happens. Althought the method onRequestException in RequestListener can handle any throwable, but the RequestProcessor does not catch error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA karma
Daniel Fagerstrom wrote: I'd like to close some JIRA issues, but I don't seem to have karma for doing that. The only workflow action I can see is Feedback required. Am I missing something? Otherwise I would appreciate if someone with enough power could upgrade my JIRA account, so that I can close issues. /Daniel You should have enough karma now. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474084 ] Carsten Ziegeler commented on COCOON-1987: -- So, is your patch still required? (Somehow the patch does not match against latest svn) Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at
