You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Nikolas List <li...@metromorph.de> on 2008/11/20 14:37:52 UTC
[C2.2, SSF] super connection doesn't work??
Hi all,
I have problems to configure two cocoon blocks, where one is a
descendant of the other (via the special "super" connection) as
described in [1]. Following the description there I would expect that
accessing an URL block1/testURL, for which no matcher in the block1s
sitemap exists, should be passed to the servlet mounted under block2.
This doesn't seem to be the case.
To be more concrete the setup is the following: I created two simple
blocks as described in [2].
In block1/src/main/resources/COB-INF/sitemap.xmap I deleted the matcher
"spring-bean" serving the bean example.
I added a dependency to block2 in block1/pom.xml and linked block2 as
super-block in
block1/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
as follows:
<bean name="test.block1.service"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:context mount-path="/block1"
context-path="blockcontext:/block1/">
<servlet:connections>
<entry key="super" value-ref="test.block2.service"/>
</servlet:connections>
</servlet:context>
</bean>
Accessing the URL localhost:8888/block1/spring-bean I would expect the
output generated by block2 as follows:
<demo>
<module>org.test:block2-old</module>
<spring>#message</spring>
</demo>
The truth is: I get a 404 http error.
Do I missunderstand the concept of inheritance in the
servlet-service-framework or is there any misconfiguration in my simple
example?
The most astonishing thing is, that it worked out of the box using the
archetypes from RC2 (1.0.0-RC2 (cocoon-core: 2.2.0-RC2,
cocoon-servlet-service-components: 1.0.0-RC1)).
Any help is appreciated.
Regards
Niko
[1]
http://cocoon.apache.org/subprojects/servlet-service/1.1/servlet-service-impl/1.1/1412_1_1.html
[2]
http://cocoon.apache.org/2.2/1291_1_1.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [C2.2, SSF] super connection doesn't work??
Posted by Nikolas List <li...@metromorph.de>.
Hi Grzegorz,
Grzegorz Kossakowski schrieb:
> Nikolas List pisze:
>> Hi all,
>>
>> I have problems to configure two cocoon blocks, where one is a
>> descendant of the other (via the special "super" connection) as
>> described in [1]. Following the description there I would expect that
>> accessing an URL block1/testURL, for which no matcher in the block1s
>> sitemap exists, should be passed to the servlet mounted under block2.
>> This doesn't seem to be the case.
>>
>> To be more concrete the setup is the following: I created two simple
>> blocks as described in [2].
>>
>> In block1/src/main/resources/COB-INF/sitemap.xmap I deleted the matcher
>> "spring-bean" serving the bean example.
>>
>> I added a dependency to block2 in block1/pom.xml and linked block2 as
>> super-block in
>> block1/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
>> as follows:
>>
>> <bean name="test.block1.service"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mount-path="/block1"
>> context-path="blockcontext:/block1/">
>> <servlet:connections>
>> <entry key="super" value-ref="test.block2.service"/>
>> </servlet:connections>
>> </servlet:context>
>> </bean>
>>
>> Accessing the URL localhost:8888/block1/spring-bean I would expect the
>> output generated by block2 as follows:
>>
>> <demo>
>> <module>org.test:block2-old</module>
>> <spring>#message</spring>
>> </demo>
>>
>> The truth is: I get a 404 http error.
>>
>> Do I missunderstand the concept of inheritance in the
>> servlet-service-framework or is there any misconfiguration in my simple
>> example?
>>
>> The most astonishing thing is, that it worked out of the box using the
>> archetypes from RC2 (1.0.0-RC2 (cocoon-core: 2.2.0-RC2,
>> cocoon-servlet-service-components: 1.0.0-RC1)).
>>
>> Any help is appreciated.
>
> Hi Nikolas,
>
> Your example looks correct and your understanding of the whole concept looks correct. Actually, it's
> hard to say what wrong is going on here. Have you checked cocoon logs? I believe SSF logs quite a
> lot of information about its "super" attempts.
>
You expect sth like
INFO servletservice.ServletServiceContext - Enter processing in servlet
service super
and
INFO servletservice.ServletServiceContext - Leaving processing in
servlet service super
??
I didn't find any such output of SSF in the logs.
Probably the relevant part in the logs are:
2008-11-21 08:11:25,553 btpool0-1 DEBUG servletservice.DispatcherServlet
- DispatcherServlet: service
servlet=org.apache.cocoon.sitemap.SitemapServlet@1e68ce4
mountPath=/block1 servletPath=/block1 pathInfo=/spring-bean
2008-11-21 08:11:25,553 btpool0-1 DEBUG internal.EnvironmentHelper -
Changing Cocoon context
2008-11-21 08:11:25,553 btpool0-1 DEBUG internal.EnvironmentHelper -
from
context(file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/)
and prefix(null)
2008-11-21 08:11:25,553 btpool0-1 DEBUG internal.EnvironmentHelper -
to
context(file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/sitemap.xmap)
and prefix()
2008-11-21 08:11:25,553 btpool0-1 DEBUG source.CocoonSourceResolver -
Resolving
'file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/'
with base
'file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/'
in context 'file:/home/niko/tmp/cocoontest/block1/'
2008-11-21 08:11:25,553 btpool0-1 DEBUG
support.DefaultListableBeanFactory - Returning cached instance of
singleton bean 'org.apache.avalon.framework.service.ServiceManager'
2008-11-21 08:11:25,554 btpool0-1 DEBUG
support.DefaultListableBeanFactory - Returning cached instance of
singleton bean 'org.apache.excalibur.source.SourceFactory/file'
2008-11-21 08:11:25,554 btpool0-1 DEBUG source.CocoonSourceResolver -
Resolved to systemID :
file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/
2008-11-21 08:11:25,554 btpool0-1 DEBUG
support.DefaultListableBeanFactory - Returning cached instance of
singleton bean 'org.apache.avalon.framework.service.ServiceManager'
2008-11-21 08:11:25,554 btpool0-1 DEBUG
support.DefaultListableBeanFactory - Returning cached instance of
singleton bean 'org.apache.excalibur.source.SourceFactory/file'
2008-11-21 08:11:25,554 btpool0-1 DEBUG internal.EnvironmentHelper - New
context is
file:///home/niko/tmp/cocoontest/block1/./src/main/resources/COB-INF/
2008-11-21 08:11:25,554 btpool0-1 DEBUG
support.DefaultListableBeanFactory - Returning cached instance of
singleton bean 'org.apache.cocoon.el.objectmodel.ObjectModel'
2008-11-21 08:11:25,554 btpool0-1 DEBUG http.HttpEnvironment - Response
successfully reset
2008-11-21 08:11:25,554 btpool0-1 WARN cocoon.access - No pipeline
matched request: spring-bean
org.apache.cocoon.ResourceNotFoundException: No pipeline matched
request: spring-bean
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:149)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
.....
> Also, full stack-trace for 404 http error would be helpful.
>
The full stacktrace is as follows:
javax.servlet.ServletException:
org.apache.cocoon.ResourceNotFoundException: No pipeline matched
request: spring-bean
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:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:468)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:443)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:264)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy3.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:106)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServlet.service(ReloadingServlet.java:91)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:131)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.apache.cocoon.servlet.DebugFilter.doFilter(DebugFilter.java:167)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingSpringFilter.doFilter(ReloadingSpringFilter.java:67)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: org.apache.cocoon.ResourceNotFoundException: No pipeline
matched request: spring-bean
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:149)
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.service(RequestProcessor.java:169)
... 38 more
Thanks for your help.
Regards
Niko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [C2.2, SSF] super connection doesn't work??
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Nikolas List pisze:
> Hi all,
>
> I have problems to configure two cocoon blocks, where one is a
> descendant of the other (via the special "super" connection) as
> described in [1]. Following the description there I would expect that
> accessing an URL block1/testURL, for which no matcher in the block1s
> sitemap exists, should be passed to the servlet mounted under block2.
> This doesn't seem to be the case.
>
> To be more concrete the setup is the following: I created two simple
> blocks as described in [2].
>
> In block1/src/main/resources/COB-INF/sitemap.xmap I deleted the matcher
> "spring-bean" serving the bean example.
>
> I added a dependency to block2 in block1/pom.xml and linked block2 as
> super-block in
> block1/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
> as follows:
>
> <bean name="test.block1.service"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/block1"
> context-path="blockcontext:/block1/">
> <servlet:connections>
> <entry key="super" value-ref="test.block2.service"/>
> </servlet:connections>
> </servlet:context>
> </bean>
>
> Accessing the URL localhost:8888/block1/spring-bean I would expect the
> output generated by block2 as follows:
>
> <demo>
> <module>org.test:block2-old</module>
> <spring>#message</spring>
> </demo>
>
> The truth is: I get a 404 http error.
>
> Do I missunderstand the concept of inheritance in the
> servlet-service-framework or is there any misconfiguration in my simple
> example?
>
> The most astonishing thing is, that it worked out of the box using the
> archetypes from RC2 (1.0.0-RC2 (cocoon-core: 2.2.0-RC2,
> cocoon-servlet-service-components: 1.0.0-RC1)).
>
> Any help is appreciated.
Hi Nikolas,
Your example looks correct and your understanding of the whole concept looks correct. Actually, it's
hard to say what wrong is going on here. Have you checked cocoon logs? I believe SSF logs quite a
lot of information about its "super" attempts.
Also, full stack-trace for 404 http error would be helpful.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [C2.2, SSF] super connection doesn't work??
Posted by Nikolas List <li...@metromorph.de>.
Hi,
thanks for your help.
Grzegorz Kossakowski schrieb:
> Nikolas List wrote:
[...]
>> The old (2.2.0-RC2) version of ServletServiceContext did directly catch
>> this Exception and did trigger a super call, as either an exception or
>> status code < 200 or >= 400 is considered.
>>
> The old behaviour was wrong.
>> Is this behaviour due to a misconfiguration of mine or is it a bug?
>>
>
> I didn't think that this might be a reason.
> Actually, I've been having similiar problems last summer and I applied
> some fixes to Cocoon core so ResourceNotFound exceptions are not
> propagated but 404 code is being returned instead.
>
> Are you using Cocoon core compiled from trunk of released version? If
> it's a Cocoon trunk then it's very likely that I've missed something.
No. I'm using the released versions from the maven repositories.
(cocoon-core 2.2.0 and servlet-service-impl 1.0.0)
After your mail I did try with cocoon-core 2.2.0 and
servlet-service-impl 1.0.0 from
http://http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2
Both don't work.
The sources from trunk (rev 720182) provide the packages cocoon-core
2.2.1-SNAPSHOT and servlet-service-components 1.1.0-SNAPSHOT? I tried
installing them as well and did adapt my poms, but the
application fails to start with various java.lang.AbstractMethodError
from rcl springreloader. What is the recommended way to use the packages
from trunk in an existing application?
Regards
Niko
>
> I cannot check my fixes right now as I don't have an access to my Git
> repository where all this work was done.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [C2.2, SSF] super connection doesn't work??
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Nikolas List wrote:
> Hi,
>
> I think I found the reason for the described problem - although no solution.
>
> Is it correct, that the "miracle" of super call is done in
> ServletServiceContext.PathDispatcher.forward(..)?
>
Yes, it's correct.
> If yes, the problem is, that the method call
>
> ServletServiceContext.this.servlet.service(request, wrappedResponse);
>
> (line 469 of ServletServiceContext.java) throws a
> ResourceNotFoundException instead of response with error code 404. The
> execution therefore continues in the finally block (line 484), never
> calling the super servlet, as the status code of the response is never
> checked.
>
> The old (2.2.0-RC2) version of ServletServiceContext did directly catch
> this Exception and did trigger a super call, as either an exception or
> status code < 200 or >= 400 is considered.
>
The old behaviour was wrong.
> Is this behaviour due to a misconfiguration of mine or is it a bug?
>
I didn't think that this might be a reason.
Actually, I've been having similiar problems last summer and I applied
some fixes to Cocoon core so ResourceNotFound exceptions are not
propagated but 404 code is being returned instead.
Are you using Cocoon core compiled from trunk of released version? If
it's a Cocoon trunk then it's very likely that I've missed something.
I cannot check my fixes right now as I don't have an access to my Git
repository where all this work was done.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [C2.2, SSF] super connection doesn't work??
Posted by Nikolas List <li...@metromorph.de>.
Hi,
I think I found the reason for the described problem - although no solution.
Is it correct, that the "miracle" of super call is done in
ServletServiceContext.PathDispatcher.forward(..)?
If yes, the problem is, that the method call
ServletServiceContext.this.servlet.service(request, wrappedResponse);
(line 469 of ServletServiceContext.java) throws a
ResourceNotFoundException instead of response with error code 404. The
execution therefore continues in the finally block (line 484), never
calling the super servlet, as the status code of the response is never
checked.
The old (2.2.0-RC2) version of ServletServiceContext did directly catch
this Exception and did trigger a super call, as either an exception or
status code < 200 or >= 400 is considered.
Is this behaviour due to a misconfiguration of mine or is it a bug?
Regards
Niko
Nikolas List schrieb:
> Hi all,
>
> I have problems to configure two cocoon blocks, where one is a
> descendant of the other (via the special "super" connection) as
> described in [1]. Following the description there I would expect that
> accessing an URL block1/testURL, for which no matcher in the block1s
> sitemap exists, should be passed to the servlet mounted under block2.
> This doesn't seem to be the case.
>
> To be more concrete the setup is the following: I created two simple
> blocks as described in [2].
>
> In block1/src/main/resources/COB-INF/sitemap.xmap I deleted the matcher
> "spring-bean" serving the bean example.
>
> I added a dependency to block2 in block1/pom.xml and linked block2 as
> super-block in
> block1/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
> as follows:
>
> <bean name="test.block1.service"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/block1"
> context-path="blockcontext:/block1/">
> <servlet:connections>
> <entry key="super" value-ref="test.block2.service"/>
> </servlet:connections>
> </servlet:context>
> </bean>
>
> Accessing the URL localhost:8888/block1/spring-bean I would expect the
> output generated by block2 as follows:
>
> <demo>
> <module>org.test:block2-old</module>
> <spring>#message</spring>
> </demo>
>
> The truth is: I get a 404 http error.
>
> Do I missunderstand the concept of inheritance in the
> servlet-service-framework or is there any misconfiguration in my simple
> example?
>
> The most astonishing thing is, that it worked out of the box using the
> archetypes from RC2 (1.0.0-RC2 (cocoon-core: 2.2.0-RC2,
> cocoon-servlet-service-components: 1.0.0-RC1)).
>
> Any help is appreciated.
>
> Regards
> Niko
>
>
>
> [1]
> http://cocoon.apache.org/subprojects/servlet-service/1.1/servlet-service-impl/1.1/1412_1_1.html
> [2]
> http://cocoon.apache.org/2.2/1291_1_1.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org