Run latest from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all When building and running the latest trunk I have some strange effects: - - The frontpage looks really ugly (http://localhost:/) I thought to have seen it already better. - - Moving over to forms sample block and click on BasicSamples/Various (Actions) the form (http://localhost:/samples/forms/form1) looks as ugly as the frontpage and I got errorrs in the log I haven't had times ago (see below). Note that the sample form loads correctly when loading a second time (moving back and click again on Variaous(Actions) ). Anyone else recognize this effects? Regards Felix Just the start of the Execption log 2008-02-01 07:57:23.195::INFO: Started SelectChannelConnector @ 0.0.0.0: [INFO] Started Jetty Server Creating a new contact row Repeater event RepeaterEventAction[Row added=0] on row 0 (contact named null) Creating a new contact row Repeater event RepeaterEventAction[Row added=0] on row 1 (contact named null) HTMLArea is deprecated. Please use alternatives instead. 2008-02-01 08:00:29.057::WARN: EXCEPTION javax.servlet.ServletException: No pipeline matched request: resource/external/forms.js ~at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:197) ~at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:84) ~at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) ~at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:512) ~at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:479) ~at org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230) ~at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) ~at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) ~at $Proxy2.service(Unknown Source) ~at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:106) ~at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) ~at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459) ~at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054) ~at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:131) ~at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045) ~at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358) ~at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231) ~at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629) ~at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453) ~at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) ~at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) ~at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) ~at org.mortbay.jetty.Server.handle(Server.java:303) ~at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452) ~at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721) ~at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509) ~at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) ~at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349) ~at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320) ~at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) 2008-02-01 08:00:29.058::WARN: Nested in javax.servlet.ServletException: No pipeline matched request: resource/external/forms.js: org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: resource/external/forms.js ~at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) ~at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) ~at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81) ~at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239) ~at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) ~at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) ~at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:351) ~at org.apache.cocoon.servlet.RequestProcessor.se
Re: [2.2] Weird NPE when concurrency
On 31.01.2008 16:35, Thorsten Scherler wrote: Have you made sure that your dispatcher transformer is configured correctly? If it is *not* threadsafe, you have to use the "prototype" scope. Otherwise you can use the "singleton" scope (which is actually the default!). This is what I always thought and how it is in 2.1 and the old 2.2. version of cocoon that forrest is using. We made a test with forrest trunk and this fixed the errors but before migrating the app I will test with defining the "singleton" scope. If you have already concurrency issues then you might try the prototype scope! With the above setup the DispatcherTransformer IS in singleton scope. Joerg
Re: [2.2] Weird NPE when concurrency
Thorsten Scherler wrote:
On Thu, 2008-01-31 at 21:41 +0100, Reinhard Poetz wrote:
Thorsten Scherler wrote:
Hi all,
we have build a webapp based on cocoon 2.2. Everything is working fine
if a single person is using the app, but as soon as we have concurrent
user the code fails with NPE in different lines of the code.
My questions are:
Every pipeline is thread safe, right?
The mounts to the different servlet (blocks) is synchronized, right?
Is there a connection timeout for inner block communications?
The architecture is as follow:
main webapp - mounts dispatcher sitemap (from block)
Main match:
Have you made sure that your dispatcher transformer is configured correctly? If
it is *not* threadsafe, you have to use the "prototype" scope. Otherwise you can
use the "singleton" scope (which is actually the default!).
This is what I always thought and how it is in 2.1 and the old 2.2.
version of cocoon that forrest is using.
Just to be clear, if you configure you transformer like this, it has to be
threadsafe.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [2.2] Weird NPE when concurrency
On Thu, 2008-01-31 at 21:41 +0100, Reinhard Poetz wrote:
> Thorsten Scherler wrote:
> > Hi all,
> >
> > we have build a webapp based on cocoon 2.2. Everything is working fine
> > if a single person is using the app, but as soon as we have concurrent
> > user the code fails with NPE in different lines of the code.
> >
> > My questions are:
> > Every pipeline is thread safe, right?
> > The mounts to the different servlet (blocks) is synchronized, right?
> > Is there a connection timeout for inner block communications?
> >
> > The architecture is as follow:
> > main webapp - mounts dispatcher sitemap (from block)
> >
> > Main match:
> >
> >
> >
> >
> >> value="{request:contextPath}"/>
> >
> >
> >
> >
> >> value="lm://resolve.structurer.{1}"/>
> >
> >
> >> value="lm://hooks-to-html.xsl"/>
> >
> >
> >
> >
> >
>
> Have you made sure that your dispatcher transformer is configured correctly?
> If
> it is *not* threadsafe, you have to use the "prototype" scope. Otherwise you
> can
> use the "singleton" scope (which is actually the default!).
This is what I always thought and how it is in 2.1 and the old 2.2.
version of cocoon that forrest is using.
We made a test with forrest trunk and this fixed the errors but before
migrating the app I will test with defining the "singleton" scope.
Cheers and will let you know whether it fixes it.
salu2
[1] http://tinyurl.com/37nh8h
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [2.2] Weird NPE when concurrency
Thorsten Scherler wrote:
Hi all,
we have build a webapp based on cocoon 2.2. Everything is working fine
if a single person is using the app, but as soon as we have concurrent
user the code fails with NPE in different lines of the code.
My questions are:
Every pipeline is thread safe, right?
The mounts to the different servlet (blocks) is synchronized, right?
Is there a connection timeout for inner block communications?
The architecture is as follow:
main webapp - mounts dispatcher sitemap (from block)
Main match:
Have you made sure that your dispatcher transformer is configured correctly? If
it is *not* threadsafe, you have to use the "prototype" scope. Otherwise you can
use the "singleton" scope (which is actually the default!).
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[jira] Updated: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-2163: - Fix Version/s: (was: 2.1.12-dev (Current SVN)) Summary: Widget Label is not Show/Hide when we change the widget state in ajax mode (was: Widget Label is not Show/Hide when we change the widget state) > Widget Label is not Show/Hide when we change the widget state in ajax mode > -- > > Key: COCOON-2163 > URL: https://issues.apache.org/jira/browse/COCOON-2163 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Carlos Chávez >Priority: Minor > Attachments: widget_states_patch.txt > > > There is an issue when we change the state of the widget. > if initially the widget is active and we change the state to invisible the > label of the widget is not hided > if initially the widget is invisible and we change the state to active the > label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2163: Assignee: Antonio Gallardo > Widget Label is not Show/Hide when we change the widget state in ajax mode > -- > > Key: COCOON-2163 > URL: https://issues.apache.org/jira/browse/COCOON-2163 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Carlos Chávez >Assignee: Antonio Gallardo >Priority: Minor > Attachments: widget_states_patch.txt > > > There is an issue when we change the state of the widget. > if initially the widget is active and we change the state to invisible the > label of the widget is not hided > if initially the widget is invisible and we change the state to active the > label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [2.2] Weird NPE when concurrency
On Thu, 2008-01-31 at 05:42 -0800, Ralph Goers wrote: > Could you post the stack trace? One thing I need to point out that the block is using A LOT communication with other blocks. Well the stack differ randomly but here is one: 2008-01-31 14:54:19.584::WARN: Nested in javax.servlet.ServletException: org.apache.cocoon.ProcessingException: Failed to process pipeline at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:65:38 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:64:70 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:63:55 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:55:42 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:49:67 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:48:36 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/portal-1.0-SNAPSHOT/sitemap.xmap:109:78: org.apache.cocoon.ProcessingException: Failed to process pipeline at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:65:38 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:64:70 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:63:55 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:55:42 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:49:67 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/work/blocks/dispatcher/sitemap.xmap:48:36 at - file:///home/thorsten/src/sadesi/portalv4/portal/target/portal-1.0-SNAPSHOT/sitemap.xmap:109:78 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:923) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:548) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:278) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:439) 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.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72) at $Proxy8.process(Unknown Source) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147) 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:147) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:88) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:147) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:88) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239) at org.apache.cocoon.components.treeprocessor.Co
Re: [2.2] Weird NPE when concurrency
Could you post the stack trace? Thorsten Scherler wrote: Hi all, we have build a webapp based on cocoon 2.2. Everything is working fine if a single person is using the app, but as soon as we have concurrent user the code fails with NPE in different lines of the code. My questions are: Every pipeline is thread safe, right? The mounts to the different servlet (blocks) is synchronized, right? Is there a connection timeout for inner block communications? The architecture is as follow: main webapp - mounts dispatcher sitemap (from block) Main match: salu2
[2.2] Weird NPE when concurrency
Hi all, we have build a webapp based on cocoon 2.2. Everything is working fine if a single person is using the app, but as soon as we have concurrent user the code fails with NPE in different lines of the code. My questions are: Every pipeline is thread safe, right? The mounts to the different servlet (blocks) is synchronized, right? Is there a connection timeout for inner block communications? The architecture is as follow: main webapp - mounts dispatcher sitemap (from block) Main match: salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
[jira] Updated: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Chávez updated COCOON-2163: -- Attachment: widget_states_patch.txt The patch included a form sample. (Visible to jira-users group) > Widget Label is not Show/Hide when we change the widget state > - > > Key: COCOON-2163 > URL: https://issues.apache.org/jira/browse/COCOON-2163 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Carlos Chávez >Priority: Minor > Fix For: 2.1.12-dev (Current SVN) > > Attachments: widget_states_patch.txt > > > There is an issue when we change the state of the widget. > if initially the widget is active and we change the state to invisible the > label of the widget is not hided > if initially the widget is invisible and we change the state to active the > label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state
Widget Label is not Show/Hide when we change the widget state - Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Priority: Minor Fix For: 2.1.12-dev (Current SVN) There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
