You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jean-Christophe Kermagoret <jc...@openbluelab.org> on 2007/07/12 12:02:38 UTC
blockcontent bug ?
No answer from users@c.a.o, try dev@c.a.o
Hi,
I'm using C22 from trunk svn :
I have created blocks through archetypes :
* cms
* common
* locator
1) Block definitions
They all define public blocks through
META-INF/cocoon/spring/servlet-service.xml
In cms/META-INF/cocoon/spring/servlet-service.xml, I have :
<bean id="org.openbluelab.cms.block"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:context mount-path="/content"
context-path="blockcontext:/cms/"/>
</bean>
In common..., I have :
<bean id="org.openbluelab.common.block"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:context mount-path="/common"
context-path="blockcontext:/common/"/>
</bean>
In locator, I have :
<bean id="org.openbluelab.locator.block"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:context mount-path="/locator"
context-path="blockcontext:/locator/"/>
</bean>
2) Sitemaps
In cms/COB-INF/sitemap.xmap, I have the following snippet :
...
<map:match pattern="config/conf.xml">
<map:generate src="docs/config/conf.xml"/>
<map:serialize type="xml"/>
</map:match>
...
==> /content/config/conf.xml returns expected xml
In common/COB-INF/sitemap.xmap , I have the following snippet :
...
<map:match pattern="test">
<map:generate src="blockcontext:/content/config/conf.xml"/>
<map:serialize type="xml"/>
</map:match>
...
==> /common/test DOESN'T return expected xml ==> ERROR
If I replace blockcontext:/content/... with blockcontext:/cms/, then it
works, but it should be the first because of mount path for cms block...
In locator/COB-INF/sitemap.xmap, I have the following snippet :
...
<map:match pattern="test">
<map:generate src="blockcontext:/common/test"/>
<map:serialize type="xml"/>
</map:match>
...
==> /locator/test DOESN'T WORK, whatever I put in common block's
sitemap, but it should be, shouldn't be it (is that correct english :-)
Last line from error message clearly indicates a problem while resolving
source.
Any ideas ?
The error message I get is the following :
[INFO] CacheImpl - Cache MISS for
PK_G-file-file:/opt/src/cocoon-22/trunk/test2/common/target/classes/COB-INF/test_S-xml-;encoding=ISO-8859-1
[WARN] cocoon - Resource not found.
at <map:serialize type="xml"> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:52:41
at <map:generate> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:51:61
at <map:match> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:50:39
javax.servlet.ServletException:
org.apache.cocoon.ResourceNotFoundException: Resource not found.
at <map:serialize type="xml"> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:52:41
at <map:generate> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:51:61
at <map:match> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:50:39
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:199)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:538)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:520)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:229)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy0.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServlet.service(ReloadingServlet.java:89)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:119)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at org.apache.cocoon.servlet.DebugFilter.doFilter(DebugFilter.java:169)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:63)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingSpringFilter.doFilter(ReloadingSpringFilter.java:71)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
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:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
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:286)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:361)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: org.apache.cocoon.ResourceNotFoundException: Resource not found.
at <map:serialize type="xml"> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:52:41
at <map:generate> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:51:61
at <map:match> -
file:/opt/src/cocoon-22/trunk/test2/locator/target/classes/COB-INF/sitemap.xmap:50:39
at
org.apache.cocoon.components.source.util.SourceUtil.handle(SourceUtil.java:330)
at
org.apache.cocoon.components.source.util.SourceUtil.getInputSource(SourceUtil.java:400)
at
org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:238)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:109)
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.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:542)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:275)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:437)
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 $Proxy7.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:143)
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:251)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
... 42 more
Caused by: org.apache.excalibur.source.SourceNotFoundException:
file:/opt/src/cocoon-22/trunk/test2/common/target/classes/COB-INF/test
doesn't exist.
at
org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150)
at
org.apache.cocoon.components.source.util.SourceUtil.getInputSource(SourceUtil.java:395)
... 71 more
Caused by: java.io.FileNotFoundException:
/opt/src/cocoon-22/trunk/test2/common/target/classes/COB-INF/test (No
such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at
org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146)
--
Jean-Christophe Kermagoret,
OpenBlueLab Technological Leader
http://www.openbluelab.org
http://forge.openbluelab.org
http://wiki.openbluelab.org
http://demo.openbluelab.org
Re: blockcontent bug ?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
> Jean-Christophe Kermagoret schrieb:
>> Thanks for the reply,
>>
>> I thought it was blockcontext role.
>> Why using servlet instead ?
>> Is blockcontext useful anymore in sitemaps ?
>
> I'm not sure, but I think this has changed because blocks-fw is already
> deprecated and servlet-service is the new one.
> Maybe Grzegorz can give more information about this.
Ah, I didn't notice that blockcontext: source is used in sitemap. It's important to say that it should be *never* used in sitemap.
Quoting Daniel's mail[1]:
It is also possible to access static resources from a block using the
blockcontext protocol. It is however not the recommended way as a block
is intended to be an isolated unit that only should be accessed through
its "public" API in form of the block protocol. The blockcontext
protocol is more intended for internal use in Cocoon and for setting up
the blockcontext property i the block servlet configuration.
The block protocol mentioned in his comment is now a servlet protocol and it should be used (with servlet connections properly set) in order
to access other blocks' resources. The public API mentioned in the quotation become, then, several sitemap matchers that enable other blocks
to access resources that are meant to be public.
Some background:
Blocks framework was replaced by Servlet Service Framework as a generalization and refinement of original idea. In servlet-service-fw every
block is a ordinal servlet that is registered at certain mount path. Such generalization of block concept enables one to integrate other
solutions[2] very seamlessly with your Cocoon-based application. The added value from Cocoon is that sitemap is very convenient way to
program servlets and servlet-service-fw introduces advanced concepts like blocks (servlets) inheritance and polymorphism.
Hope that helps.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/68522
[2] http://thread.gmane.org/gmane.text.xml.cocoon.devel/73908/focus=74083
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: blockcontent bug ?
Posted by Felix Knecht <fe...@apache.org>.
Jean-Christophe Kermagoret schrieb:
> Thanks for the reply,
>
> I thought it was blockcontext role.
> Why using servlet instead ?
> Is blockcontext useful anymore in sitemaps ?
I'm not sure, but I think this has changed because blocks-fw is already
deprecated and servlet-service is the new one.
Maybe Grzegorz can give more information about this.
>
> JC
>
> Felix Knecht a écrit :
>> Jean-Christophe Kermagoret schrieb:
>>
>>> No answer from users@c.a.o, try dev@c.a.o
>>>
>>> Hi,
>>> I'm using C22 from trunk svn :
>>>
>>> I have created blocks through archetypes :
>>> * cms
>>> * common
>>> * locator
>>>
>>> 1) Block definitions
>>>
>>> They all define public blocks through
>>> META-INF/cocoon/spring/servlet-service.xml
>>>
>>> In cms/META-INF/cocoon/spring/servlet-service.xml, I have :
>>> <bean id="org.openbluelab.cms.block"
>>> class="org.apache.cocoon.sitemap.SitemapServlet">
>>> <servlet:context mount-path="/content"
>>> context-path="blockcontext:/cms/"/>
>>> </bean>
>>>
>>> In common..., I have :
>>> <bean id="org.openbluelab.common.block"
>>> class="org.apache.cocoon.sitemap.SitemapServlet">
>>> <servlet:context mount-path="/common"
>>> context-path="blockcontext:/common/"/>
>>> </bean>
>>>
>>>
>>
>> I think the servlet connections are missing. To get stuff from cms block
>> in commons block this should look like
>>
>> <bean id="org.openbluelab.common.block"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mount-path="/common"
>> context-path="blockcontext:/common/" >
>> <servlet:connections>
>> <entry key="cms" value-ref="org.openbluelab.cms.block"" />
>> </servlet:connections>
>> </servlet:context>
>> </bean>
>>
>>
>>> In locator, I have :
>>> <bean id="org.openbluelab.locator.block"
>>> class="org.apache.cocoon.sitemap.SitemapServlet">
>>> <servlet:context mount-path="/locator"
>>> context-path="blockcontext:/locator/"/>
>>> </bean>
>>>
>>> 2) Sitemaps
>>>
>>> In cms/COB-INF/sitemap.xmap, I have the following snippet :
>>> ...
>>> <map:match pattern="config/conf.xml">
>>> <map:generate src="docs/config/conf.xml"/>
>>> <map:serialize type="xml"/>
>>> </map:match>
>>> ...
>>>
>>> ==> /content/config/conf.xml returns expected xml
>>>
>>> In common/COB-INF/sitemap.xmap , I have the following snippet :
>>> ...
>>> <map:match pattern="test">
>>> <map:generate
>>> src="blockcontext:/content/config/conf.xml"/>
>>> <map:serialize type="xml"/>
>>> </map:match>
>>>
>>
>> And this should look like
>>
>> <map:match pattern="test">
>> <map:generate src="servlet:cms:/config/conf.xml"/>
>> <map:serialize type="xml"/>
>> </map:match>
>>
>>
>> It may also help to read the cforms migration guide what can give you an
>> idea of how it works.
>> http://cocoon.zones.apache.org/dev-docs/2.2/blocks/forms/1.0/1351_1_1.html
>>
>>
>> HTH
>> Felix
>>
>>
>
>
Re: blockcontent bug ?
Posted by Jean-Christophe Kermagoret <jc...@openbluelab.org>.
Thanks for the reply,
I thought it was blockcontext role.
Why using servlet instead ?
Is blockcontext useful anymore in sitemaps ?
JC
Felix Knecht a écrit :
> Jean-Christophe Kermagoret schrieb:
>
>> No answer from users@c.a.o, try dev@c.a.o
>>
>> Hi,
>> I'm using C22 from trunk svn :
>>
>> I have created blocks through archetypes :
>> * cms
>> * common
>> * locator
>>
>> 1) Block definitions
>>
>> They all define public blocks through
>> META-INF/cocoon/spring/servlet-service.xml
>>
>> In cms/META-INF/cocoon/spring/servlet-service.xml, I have :
>> <bean id="org.openbluelab.cms.block"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mount-path="/content"
>> context-path="blockcontext:/cms/"/>
>> </bean>
>>
>> In common..., I have :
>> <bean id="org.openbluelab.common.block"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mount-path="/common"
>> context-path="blockcontext:/common/"/>
>> </bean>
>>
>>
>
> I think the servlet connections are missing. To get stuff from cms block
> in commons block this should look like
>
> <bean id="org.openbluelab.common.block"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/common"
> context-path="blockcontext:/common/" >
> <servlet:connections>
> <entry key="cms" value-ref="org.openbluelab.cms.block"" />
> </servlet:connections>
> </servlet:context>
> </bean>
>
>
>> In locator, I have :
>> <bean id="org.openbluelab.locator.block"
>> class="org.apache.cocoon.sitemap.SitemapServlet">
>> <servlet:context mount-path="/locator"
>> context-path="blockcontext:/locator/"/>
>> </bean>
>>
>> 2) Sitemaps
>>
>> In cms/COB-INF/sitemap.xmap, I have the following snippet :
>> ...
>> <map:match pattern="config/conf.xml">
>> <map:generate src="docs/config/conf.xml"/>
>> <map:serialize type="xml"/>
>> </map:match>
>> ...
>>
>> ==> /content/config/conf.xml returns expected xml
>>
>> In common/COB-INF/sitemap.xmap , I have the following snippet :
>> ...
>> <map:match pattern="test">
>> <map:generate
>> src="blockcontext:/content/config/conf.xml"/>
>> <map:serialize type="xml"/>
>> </map:match>
>>
>
> And this should look like
>
> <map:match pattern="test">
> <map:generate src="servlet:cms:/config/conf.xml"/>
> <map:serialize type="xml"/>
> </map:match>
>
>
> It may also help to read the cforms migration guide what can give you an
> idea of how it works.
> http://cocoon.zones.apache.org/dev-docs/2.2/blocks/forms/1.0/1351_1_1.html
>
> HTH
> Felix
>
>
--
Jean-Christophe Kermagoret,
OpenBlueLab Technological Leader
http://www.openbluelab.org
http://forge.openbluelab.org
http://wiki.openbluelab.org
http://demo.openbluelab.org
Re: blockcontent bug ?
Posted by Felix Knecht <fe...@apache.org>.
Jean-Christophe Kermagoret schrieb:
> No answer from users@c.a.o, try dev@c.a.o
>
> Hi,
> I'm using C22 from trunk svn :
>
> I have created blocks through archetypes :
> * cms
> * common
> * locator
>
> 1) Block definitions
>
> They all define public blocks through
> META-INF/cocoon/spring/servlet-service.xml
>
> In cms/META-INF/cocoon/spring/servlet-service.xml, I have :
> <bean id="org.openbluelab.cms.block"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/content"
> context-path="blockcontext:/cms/"/>
> </bean>
>
> In common..., I have :
> <bean id="org.openbluelab.common.block"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/common"
> context-path="blockcontext:/common/"/>
> </bean>
>
I think the servlet connections are missing. To get stuff from cms block
in commons block this should look like
<bean id="org.openbluelab.common.block"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:context mount-path="/common"
context-path="blockcontext:/common/" >
<servlet:connections>
<entry key="cms" value-ref="org.openbluelab.cms.block"" />
</servlet:connections>
</servlet:context>
</bean>
> In locator, I have :
> <bean id="org.openbluelab.locator.block"
> class="org.apache.cocoon.sitemap.SitemapServlet">
> <servlet:context mount-path="/locator"
> context-path="blockcontext:/locator/"/>
> </bean>
>
> 2) Sitemaps
>
> In cms/COB-INF/sitemap.xmap, I have the following snippet :
> ...
> <map:match pattern="config/conf.xml">
> <map:generate src="docs/config/conf.xml"/>
> <map:serialize type="xml"/>
> </map:match>
> ...
>
> ==> /content/config/conf.xml returns expected xml
>
> In common/COB-INF/sitemap.xmap , I have the following snippet :
> ...
> <map:match pattern="test">
> <map:generate
> src="blockcontext:/content/config/conf.xml"/>
> <map:serialize type="xml"/>
> </map:match>
And this should look like
<map:match pattern="test">
<map:generate src="servlet:cms:/config/conf.xml"/>
<map:serialize type="xml"/>
</map:match>
It may also help to read the cforms migration guide what can give you an
idea of how it works.
http://cocoon.zones.apache.org/dev-docs/2.2/blocks/forms/1.0/1351_1_1.html
HTH
Felix
Re: blockcontent bug ?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jean-Christophe Kermagoret pisze:
> No answer from users@c.a.o, try dev@c.a.o
I was going to answer to your post soon but I'm little bit overloaded now. It would be helpful if you could provide test application
(blocks) that would allow me to quickly reproduce your problem.
I have no time to do it manually basing on your description, sorry.
> Hi,
> I'm using C22 from trunk svn :
>
<snip/>
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/