non-descript cocoon error

Does this mean anything to anyone?  It happens when I
include a
transform in the pipeline with an xpathdirectorygenerator. 
I'm sure
I'm doing something dumb but "Internal Cocoon
Problem" doesn't help
much in determing what that something is.  I can return the
raw xml if
I omit the transform.  I can transform the xml from the
command line
without problem. When I put the two together this is the
stack trace.
Thanks,
--tim

ERROR   (2006-01-22) 14:52.14:532   [access]
(/gallery/index.xml)
PoolThread-4/CocoonServlet: Internal Cocoon Problem
org.apache.cocoon.ProcessingException: Failed to process
pipeline
	at <map:serialize type="xml"> -
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:41:36
	at <map:generate type="xpathdirectory"> -
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:33:81
	at <map:serialize type="xml"> -
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:47:36
	at <map:transform> -
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:46:69
	at <map:generate> -
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:45:66
	at <map:mount> -
file:/C:/src/apache-forrest-trunk-s/plugins/org.apache.forre
st.plugin.input.PhotoGallery/build/tmp/input.xmap:38:146
	at <map:mount> -
file:/C:/src/apache-forrest-trunk-s/main/webapp/forrest.xmap
:223:46
	at <map:mount> -
file:/C:/src/apache-forrest-trunk-s/main/webapp/sitemap.xmap
:485:74
	at
org.apache.cocoon.ProcessingException.throwLocated(Processin
gException.java:144)
	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.handleException(AbstractProcessingPipeline.java:894)
	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:271)
	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.process(AbstractProcessingPipeline.java:722)
	at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX
(SitemapSource.java:347)
	at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceU
til.java:97)
	at
org.apache.cocoon.components.source.SourceUtil.parse(SourceU
til.java:276)
	at
org.apache.cocoon.generation.FileGenerator.generate(FileGene
rator.java:118)
	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:259)
	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.process(AbstractProcessingPipeline.java:437)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Serialize
Node.invoke(SerializeNode.java:137)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNod
e.invoke(SelectNode.java:81)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNod
e.invoke(SelectNode.java:81)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
	at org.apache.cocoon.Cocoon.process(Cocoon.java:557)
	at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServle
t.java:364)
	at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder
.java:354)
	at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Web
ApplicationHandler.java:294)
	at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandl
er.java:567)
	at
org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
	at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebAp
plicationContext.java:525)
	at
org.mortbay.http.HttpContext.handle(HttpContext.java:1758)
	at org.mortbay.http.HttpServer.service(HttpServer.java:879)
	at
org.mortbay.http.HttpConnection.service(HttpConnection.java:
790)
	at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.ja
va:952)
	at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:8
07)
	at
org.mortbay.http.SocketListener.handleConnection(SocketListe
ner.java:197)
	at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:2
89)
	at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:5
01)
Caused by: java.lang.RuntimeException
	at
org.apache.xalan.transformer.TransformerImpl.run(Transformer
Impl.java:3493)
	at
org.apache.xalan.transformer.TransformerHandlerImpl.endDocum
ent(TransformerHandlerImpl.java:406)
	at
org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXM
LPipe.java:55)
	at
org.apache.cocoon.transformation.TraxTransformer.endDocument
(TraxTransformer.java:585)
	at
org.apache.cocoon.environment.internal.EnvironmentChanger.en
dDocument(EnvironmentStack.java:119)
	at
org.apache.cocoon.components.sax.XMLTeePipe.endDocument(XMLT
eePipe.java:67)
	at
org.apache.cocoon.generation.DirectoryGenerator.generate(Dir
ectoryGenerator.java:269)
	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:225)

Tim Williams wrote:
> Does this mean anything to anyone?  It happens when I
include a
> transform in the pipeline with an
xpathdirectorygenerator.  I'm sure
> I'm doing something dumb but "Internal Cocoon
Problem" doesn't help
> much in determing what that something is.  I can return
the raw xml if
> I omit the transform.  I can transform the xml from the
command line
> without problem. When I put the two together this is
the stack trace.

The problem is not in Cocoon but in Xalan, see below:

> ERROR   (2006-01-22) 14:52.14:532   [access]
(/gallery/index.xml)
> PoolThread-4/CocoonServlet: Internal Cocoon Problem
> org.apache.cocoon.ProcessingException: Failed to
process pipeline
> 	at <map:serialize type="xml"> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:41:36

...

> Caused by: java.lang.RuntimeException
> 	at
org.apache.xalan.transformer.TransformerImpl.run(Transformer
Impl.java:3493)

I appreciate that this error isn't much more helpful, but at
least it 
gives you another place to look and also gives me a clue
that the 
problem is in the XSL.

Have you tested it from the command line using Xalan or some
other XSLT 
processor. Perhaps it was a different version of Xalan?

These are all guesses in the hope that they may give you
inspiration, I 
can't be any more direct help I'm afraid.

Ross

You need to attach the snippet from the xmap.

salu2

El dom, 22-01-2006 a las 15:01 -0500, Tim Williams
escribió:
> Does this mean anything to anyone?  It happens when I
include a
> transform in the pipeline with an
xpathdirectorygenerator.  I'm sure
> I'm doing something dumb but "Internal Cocoon
Problem" doesn't help
> much in determing what that something is.  I can return
the raw xml if
> I omit the transform.  I can transform the xml from the
command line
> without problem. When I put the two together this is
the stack trace.
> Thanks,
> --tim
> 
> ERROR   (2006-01-22) 14:52.14:532   [access]
(/gallery/index.xml)
> PoolThread-4/CocoonServlet: Internal Cocoon Problem
> org.apache.cocoon.ProcessingException: Failed to
process pipeline
> 	at <map:serialize type="xml"> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:41:36
> 	at <map:generate
type="xpathdirectory"> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:33:81
> 	at <map:serialize type="xml"> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:47:36
> 	at <map:transform> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:46:69
> 	at <map:generate> -
>
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:45:66
> 	at <map:mount> -
>
file:/C:/src/apache-forrest-trunk-s/plugins/org.apache.forre
st.plugin.input.PhotoGallery/build/tmp/input.xmap:38:146
> 	at <map:mount> -
>
file:/C:/src/apache-forrest-trunk-s/main/webapp/forrest.xmap
:223:46
> 	at <map:mount> -
>
file:/C:/src/apache-forrest-trunk-s/main/webapp/sitemap.xmap
:485:74
> 	at
org.apache.cocoon.ProcessingException.throwLocated(Processin
gException.java:144)
> 	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.handleException(AbstractProcessingPipeline.java:894)
> 	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:271)
> 	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.process(AbstractProcessingPipeline.java:722)
> 	at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX
(SitemapSource.java:347)
> 	at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceU
til.java:97)
> 	at
org.apache.cocoon.components.source.SourceUtil.parse(SourceU
til.java:276)
> 	at
org.apache.cocoon.generation.FileGenerator.generate(FileGene
rator.java:118)
> 	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:259)
> 	at
org.apache.cocoon.components.pipeline.AbstractProcessingPipe
line.process(AbstractProcessingPipeline.java:437)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Serialize
Node.invoke(SerializeNode.java:137)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
> 	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNod
e.invoke(SelectNode.java:81)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
> 	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNod
e.invoke(SelectNode.java:81)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
> 	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode
.invoke(MountNode.java:114)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:55
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Preparabl
eMatchNode.invoke(PreparableMatchNode.java:116)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineN
ode.invoke(PipelineNode.java:155)
> 	at
org.apache.cocoon.components.treeprocessor.AbstractParentPro
cessingNode.invokeNodes(AbstractParentProcessingNode.java:77
)
> 	at
org.apache.cocoon.components.treeprocessor.sitemap.Pipelines
Node.invoke(PipelinesNode.java:95)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:292)
> 	at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProce
ssor.process(ConcreteTreeProcessor.java:223)
> 	at
org.apache.cocoon.components.treeprocessor.TreeProcessor.pro
cess(TreeProcessor.java:289)
> 	at org.apache.cocoon.Cocoon.process(Cocoon.java:557)
> 	at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServle
t.java:364)
> 	at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> 	at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder
.java:354)
> 	at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Web
ApplicationHandler.java:294)
> 	at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandl
er.java:567)
> 	at
org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
> 	at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebAp
plicationContext.java:525)
> 	at
org.mortbay.http.HttpContext.handle(HttpContext.java:1758)
> 	at
org.mortbay.http.HttpServer.service(HttpServer.java:879)
> 	at
org.mortbay.http.HttpConnection.service(HttpConnection.java:
790)
> 	at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.ja
va:952)
> 	at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:8
07)
> 	at
org.mortbay.http.SocketListener.handleConnection(SocketListe
ner.java:197)
> 	at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:2
89)
> 	at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:5
01)
> Caused by: java.lang.RuntimeException
> 	at
org.apache.xalan.transformer.TransformerImpl.run(Transformer
Impl.java:3493)
> 	at
org.apache.xalan.transformer.TransformerHandlerImpl.endDocum
ent(TransformerHandlerImpl.java:406)
> 	at
org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXM
LPipe.java:55)
> 	at
org.apache.cocoon.transformation.TraxTransformer.endDocument
(TraxTransformer.java:585)
> 	at
org.apache.cocoon.environment.internal.EnvironmentChanger.en
dDocument(EnvironmentStack.java:119)
> 	at
org.apache.cocoon.components.sax.XMLTeePipe.endDocument(XMLT
eePipe.java:67)
> 	at
org.apache.cocoon.generation.DirectoryGenerator.generate(Dir
ectoryGenerator.java:269)
> 	at
org.apache.cocoon.components.pipeline.impl.AbstractCachingPr
ocessingPipeline.processXMLPipeline(AbstractCachingProcessin
gPipeline.java:225)
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

El dom, 22-01-2006 a las 20:42 +0000, Ross Gardler
escribió:
> Tim Williams wrote:
> > Does this mean anything to anyone?  It happens
when I include a
> > transform in the pipeline with an
xpathdirectorygenerator.  I'm sure
> > I'm doing something dumb but "Internal Cocoon
Problem" doesn't help
> > much in determing what that something is.  I can
return the raw xml if
> > I omit the transform.  I can transform the xml
from the command line
> > without problem. When I put the two together this
is the stack trace.
> 
> The problem is not in Cocoon but in Xalan, see below:
> 
> > ERROR   (2006-01-22) 14:52.14:532   [access]
(/gallery/index.xml)
> > PoolThread-4/CocoonServlet: Internal Cocoon
Problem
> > org.apache.cocoon.ProcessingException: Failed to
process pipeline
> > 	at <map:serialize type="xml"> -
> >
file:/C:/src/apache-forrest-trunk-s/build/plugins/org.apache
.forrest.plugin.input.PhotoGallery/input.xmap:41:36
> 
> ...
> 
> > Caused by: java.lang.RuntimeException
> > 	at
org.apache.xalan.transformer.TransformerImpl.run(Transformer
Impl.java:3493)
> 
> I appreciate that this error isn't much more helpful,
but at least it 
> gives you another place to look and also gives me a
clue that the 
> problem is in the XSL.
> 
> Have you tested it from the command line using Xalan or
some other XSLT 
> processor. Perhaps it was a different version of Xalan?

...or xsl version 2.0?

> 
> These are all guesses in the hope that they may give
you inspiration, I 
> can't be any more direct help I'm afraid.
> 
> Ross
> 
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
> You need to attach the snippet from the xmap.

As Ross suggested, I did check my xalan version and updated
it to use
the forrest version of xalan.  The transform still works on
the
command line and this snippet works if I remove the
transform step. 
They both work independently just not together.  I've
simplified the
xsl to be no more than a helloworld stylesheet just to make
sure. 
I've seen this work before and its simple stuff, just can't
figure out
what the heck i'm doing wrong here.  Thanks to all for the
help....
--tim
      <map:match
pattern="gallery/index.xml">
         <map:generate type="xpathdirectory"
src="{lm:project.images/gallery/}">
            <map:parameter name="depth"
value="99"/>
            <map:parameter name="xpath"
value="/"/>
            <map:parameter name="sort"
value="lastmodified"/>
            <map:parameter name="reverse"
value="true"/>
            <map:parameter name="exclude"
value=".svn$"/>
         </map:generate>
        <map:transform
src="resources/stylesheets/galleryHome.xsl"/>
        <map:serialize type="xml"/>
      </map:match>

El dom, 22-01-2006 a las 16:43 -0500, Tim Williams
escribió:
> On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
> > You need to attach the snippet from the xmap.
> 
> As Ross suggested, I did check my xalan version and
updated it to use
> the forrest version of xalan.  The transform still
works on the
> command line and this snippet works if I remove the
transform step. 
> They both work independently just not together.

The output of the generator has namespaces, did your xsl
takes this into
account?

>   I've simplified the
> xsl to be no more than a helloworld stylesheet just to
make sure. 

Ok, then let us step back and try something simpler maybe
you added a
method that is not valid. Try something like
<xsl:template match="/">
 <xsl:copy-of select="*"/>
</xsl:template>

...and see what it gives.

Do you remember your last modification?

> I've seen this work before 

How? something like:
java -jar saxon8.jar -o status.xml log.xml
tools/svn2changes.xsl

> and its simple stuff, just can't figure out
> what the heck i'm doing wrong here.  Thanks to all for
the help....
> --tim
>       <map:match
pattern="gallery/index.xml">
>          <map:generate
type="xpathdirectory"
src="{lm:project.images/gallery/}">
>             <map:parameter name="depth"
value="99"/>
>             <map:parameter name="xpath"
value="/"/>
>             <map:parameter name="sort"
value="lastmodified"/>
>             <map:parameter name="reverse"
value="true"/>
>             <map:parameter name="exclude"
value=".svn$"/>
>          </map:generate>
>         <map:transform
src="resources/stylesheets/galleryHome.xsl"/>
>         <map:serialize type="xml"/>
>       </map:match>

Actually if you say without the transformer it is working, I
need to see
this xsl to say something.

Anyway if you use <xsl:stylesheet
version="2.0"/> that could be the
reason for failing, since I dunno whether cocoon supports
2.0.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
> El dom, 22-01-2006 a las 16:43 -0500, Tim Williams
escribió:
> > On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
> > > You need to attach the snippet from the xmap.
> >
> > As Ross suggested, I did check my xalan version
and updated it to use
> > the forrest version of xalan.  The transform still
works on the
> > command line and this snippet works if I remove
the transform step.
> > They both work independently just not together.
>
> The output of the generator has namespaces, did your
xsl takes this into
> account?

yes.

> >   I've simplified the
> > xsl to be no more than a helloworld stylesheet
just to make sure.
>
> Ok, then let us step back and try something simpler
maybe you added a
> method that is not valid. Try something like
> <xsl:template match="/">
>  <xsl:copy-of select="*"/>
> </xsl:template>
>
> ...and see what it gives.
>
> Do you remember your last modification?

I've never gotten this to work.  I'm doing essentially the
same thing
in the Blog plugin though.

> > I've seen this work before
>
> How? something like:
> java -jar saxon8.jar -o status.xml log.xml
tools/svn2changes.xsl

Sorry, I meant I've seen essentially that same thing
(xpathdirgen)
work before when used in much the same way.

> > and its simple stuff, just can't figure out
> > what the heck i'm doing wrong here.  Thanks to all
for the help....
> > --tim
> >       <map:match
pattern="gallery/index.xml">
> >          <map:generate
type="xpathdirectory"
src="{lm:project.images/gallery/}">
> >             <map:parameter
name="depth" value="99"/>
> >             <map:parameter
name="xpath" value="/"/>
> >             <map:parameter
name="sort" value="lastmodified"/>
> >             <map:parameter
name="reverse" value="true"/>
> >             <map:parameter
name="exclude" value=".svn$"/>
> >          </map:generate>
> >         <map:transform
src="resources/stylesheets/galleryHome.xsl"/>
> >         <map:serialize
type="xml"/>
> >       </map:match>
>
> Actually if you say without the transformer it is
working, I need to see
> this xsl to say something.

I can't even get what you wrote above working -- though mine
wasn't
much more than that. Here's your version:

<xsl:stylesheet version="1.0"
                xmlnssl=&q
uot;http://www
.w3.org/1999/XSL/Transform"
                xmlns:dir="http
://apache.org/cocoon/directory/2.0">

  <xsl:template match="/">
    <xsl:copy-of select="*"/>
  </xsl:template>

</xsl:stylesheet>

> Anyway if you use <xsl:stylesheet
version="2.0"/> that could be the
> reason for failing, since I dunno whether cocoon
supports 2.0.

No, it's 1.0.  Since the generator works and the stylesheet
alone
works, I wonder what could make it not work together?  Just
to make
sure, I've tried applying the stylesheet to a xml based on a
regular
file generator and it works fine.  I'm wondering if the
xpathdirectorygenerator somehow isn't returning the data
fast enough
for the transformer?  I'm not familiar with how the
transformers
operate and how they would handle a slow generator - seems
like this
wouldn't be an issue it'd just handle the event whenever it
fired but
I don't know.

Thanks for the help...
--tim

On 1/22/06, Tim Williams <williamstwgmail.com> wrote:
> On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
> > El dom, 22-01-2006 a las 16:43 -0500, Tim Williams
escribió:
> > > On 1/22/06, Thorsten Scherler
<thorstenapache.org> wrote:
> > > > You need to attach the snippet from the
xmap.
> > >
> > > As Ross suggested, I did check my xalan
version and updated it to use
> > > the forrest version of xalan.  The transform
still works on the
> > > command line and this snippet works if I
remove the transform step.
> > > They both work independently just not
together.
> >
> > The output of the generator has namespaces, did
your xsl takes this into
> > account?
>
> yes.
>
> > >   I've simplified the
> > > xsl to be no more than a helloworld
stylesheet just to make sure.
> >
> > Ok, then let us step back and try something
simpler maybe you added a
> > method that is not valid. Try something like
> > <xsl:template match="/">
> >  <xsl:copy-of select="*"/>
> > </xsl:template>
> >
> > ...and see what it gives.
> >
> > Do you remember your last modification?
>
> I've never gotten this to work.  I'm doing essentially
the same thing
> in the Blog plugin though.
>
> > > I've seen this work before
> >
> > How? something like:
> > java -jar saxon8.jar -o status.xml log.xml
tools/svn2changes.xsl
>
> Sorry, I meant I've seen essentially that same thing
(xpathdirgen)
> work before when used in much the same way.
>
> > > and its simple stuff, just can't figure out
> > > what the heck i'm doing wrong here.  Thanks
to all for the help....
> > > --tim
> > >       <map:match
pattern="gallery/index.xml">
> > >          <map:generate
type="xpathdirectory"
src="{lm:project.images/gallery/}">
> > >             <map:parameter
name="depth" value="99"/>
> > >             <map:parameter
name="xpath" value="/"/>
> > >             <map:parameter
name="sort" value="lastmodified"/>
> > >             <map:parameter
name="reverse" value="true"/>
> > >             <map:parameter
name="exclude" value=".svn$"/>
> > >          </map:generate>
> > >         <map:transform
src="resources/stylesheets/galleryHome.xsl"/>
> > >         <map:serialize
type="xml"/>
> > >       </map:match>
> >
> > Actually if you say without the transformer it is
working, I need to see
> > this xsl to say something.
>
> I can't even get what you wrote above working -- though
mine wasn't
> much more than that. Here's your version:
>
> <xsl:stylesheet version="1.0"
>                 xmlnssl=&q
uot;http://www
.w3.org/1999/XSL/Transform"
>                 xmlns:dir="http
://apache.org/cocoon/directory/2.0">
>
>   <xsl:template match="/">
>     <xsl:copy-of select="*"/>
>   </xsl:template>
>
> </xsl:stylesheet>
>
> > Anyway if you use <xsl:stylesheet
version="2.0"/> that could be the
> > reason for failing, since I dunno whether cocoon
supports 2.0.
>
> No, it's 1.0.  Since the generator works and the
stylesheet alone
> works, I wonder what could make it not work together? 
Just to make
> sure, I've tried applying the stylesheet to a xml based
on a regular
> file generator and it works fine.  I'm wondering if the
> xpathdirectorygenerator somehow isn't returning the
data fast enough
> for the transformer?  I'm not familiar with how the
transformers
> operate and how they would handle a slow generator -
seems like this
> wouldn't be an issue it'd just handle the event
whenever it fired but
> I don't know.
>
> Thanks for the help...
> --tim

These seem related.  Ross, if you can remember if you
resolved this
issue please let me know what it was.

http://www.nabble.com/XPathDir
ectoryGenerator-gives-Runtime-exception-p404954.html

http://comments.gmane.org/gmane.text.xml.cocoon.user/1
8311

Anyway, I've done a bit more testing and it turns out that
it might
have been my use of the xpathgenerator that caused my
troubles.  I
still don't really know *why* it doesn't work, just what a
workaround
is.

My problem was that I had a small little xml file that was
acting like
a metacard for a photo album and, since it was small, I just
wanted it
to return the whole thing so I set the xpath parameter like
this:

<map:parameter name="xpath"
value="/"/>

This got me the runtime error described in this thread.  For
context,
the xml file looks like this:
<?xml version="1.0"?>
<albuminfo>
    <title>my album title</title>
    <description>A description of the demo
album</description>
</albuminfo>

I tried value="/albuminfo/title" and it works
fine.  I'm not sure why
value="/" works fine to just serialize but when
the transformer is
inserted it doesn't work?  Anyway, I finally get what I want
by using
value="/albuminfo/*"  Now folks can easily extend
the descriptors they
have available for the main gallery entry/index page by
simply adding
a child element to albuminfo and referencing it in the
galleryInfo.xsl, which is really all I wanted here.

Thanks again for the help on this...

--tim

Tim Williams wrote:
> On 1/22/06, Tim Williams <williamstwgmail.com> wrote:
> 
>>On 1/22/06, Thorsten Scherler <thorstenapache.org> wrote:
>>
>>>El dom, 22-01-2006 a las 16:43 -0500, Tim
Williams escribió:
>>>
>>>>On 1/22/06, Thorsten Scherler
<thorstenapache.org> wrote:
>>>>
>>>>>You need to attach the snippet from the
xmap.
>>>>
>>>>As Ross suggested, I did check my xalan
version and updated it to use
>>>>the forrest version of xalan.  The transform
still works on the
>>>>command line and this snippet works if I
remove the transform step.
>>>>They both work independently just not
together.
>>>
>>>The output of the generator has namespaces, did
your xsl takes this into
>>>account?
>>
>>yes.
>>
>>
>>>>  I've simplified the
>>>>xsl to be no more than a helloworld
stylesheet just to make sure.
>>>
>>>Ok, then let us step back and try something
simpler maybe you added a
>>>method that is not valid. Try something like
>>><xsl:template match="/">
>>> <xsl:copy-of select="*"/>
>>></xsl:template>
>>>
>>>...and see what it gives.
>>>
>>>Do you remember your last modification?
>>
>>I've never gotten this to work.  I'm doing
essentially the same thing
>>in the Blog plugin though.
>>
>>
>>>>I've seen this work before
>>>
>>>How? something like:
>>>java -jar saxon8.jar -o status.xml log.xml
tools/svn2changes.xsl
>>
>>Sorry, I meant I've seen essentially that same thing
(xpathdirgen)
>>work before when used in much the same way.
>>
>>
>>>>and its simple stuff, just can't figure out
>>>>what the heck i'm doing wrong here.  Thanks
to all for the help....
>>>>--tim
>>>>      <map:match
pattern="gallery/index.xml">
>>>>         <map:generate
type="xpathdirectory"
src="{lm:project.images/gallery/}">
>>>>            <map:parameter
name="depth" value="99"/>
>>>>            <map:parameter
name="xpath" value="/"/>
>>>>            <map:parameter
name="sort" value="lastmodified"/>
>>>>            <map:parameter
name="reverse" value="true"/>
>>>>            <map:parameter
name="exclude" value=".svn$"/>
>>>>         </map:generate>
>>>>        <map:transform
src="resources/stylesheets/galleryHome.xsl"/>
>>>>        <map:serialize
type="xml"/>
>>>>      </map:match>
>>>
>>>Actually if you say without the transformer it
is working, I need to see
>>>this xsl to say something.
>>
>>I can't even get what you wrote above working --
though mine wasn't
>>much more than that. Here's your version:
>>
>><xsl:stylesheet version="1.0"
>>                xmlnssl=&q
uot;http://www
.w3.org/1999/XSL/Transform"
>>                xmlns:dir="http
://apache.org/cocoon/directory/2.0">
>>
>>  <xsl:template match="/">
>>    <xsl:copy-of select="*"/>
>>  </xsl:template>
>>
>></xsl:stylesheet>
>>
>>>Anyway if you use <xsl:stylesheet
version="2.0"/> that could be the
>>>reason for failing, since I dunno whether cocoon
supports 2.0.
>>
>>No, it's 1.0.  Since the generator works and the
stylesheet alone
>>works, I wonder what could make it not work
together?  Just to make
>>sure, I've tried applying the stylesheet to a xml
based on a regular
>>file generator and it works fine.  I'm wondering if
the
>>xpathdirectorygenerator somehow isn't returning the
data fast enough
>>for the transformer?  I'm not familiar with how the
transformers
>>operate and how they would handle a slow generator -
seems like this
>>wouldn't be an issue it'd just handle the event
whenever it fired but
>>I don't know.
>>
>>Thanks for the help...
>>--tim
> 
> 
> These seem related.  Ross, if you can remember if you
resolved this
> issue please let me know what it was.
> 
> http://www.nabble.com/XPathDir
ectoryGenerator-gives-Runtime-exception-p404954.html

Wow, aren't archives great! I have had exactly the same
problem in the 
past and I had no recollection o it. Now I recall hours of
throwing my 
rubber brick at the computer trying to solve this one.

The bottom line is that I never solved the XPath Geerator
problem. 
Looking at the resume plugin now it seems I reverted to
using the 
directory generator and used XSL to filter to get the parts
of the 
directory listing I needed.

> Anyway, I've done a bit more testing and it turns out
that it might
> have been my use of the xpathgenerator that caused my
troubles.  I
> still don't really know *why* it doesn't work, just
what a workaround
> is.
> 
> My problem was that I had a small little xml file that
was acting like
> a metacard for a photo album and, since it was small, I
just wanted it
> to return the whole thing so I set the xpath parameter
like this:
> 
> <map:parameter name="xpath"
value="/"/>

Looking at my mail above I was doing the same thing, for
testing purposes.

> I tried value="/albuminfo/title" and it works
fine.  I'm not sure why
> value="/" works fine to just serialize but
when the transformer is
> inserted it doesn't work?

Well, your "workaround" is better than mine was,
so that's an improvement.

>  Anyway, I finally get what I want by using
> value="/albuminfo/*"  Now folks can easily
extend the descriptors they
> have available for the main gallery entry/index page by
simply adding
> a child element to albuminfo and referencing it in the
> galleryInfo.xsl, which is really all I wanted here.

I'm really looking forward to your improvements to the Photo
Album. We 
discussed doing the stuff you are talking about some time
ago. It's 
always been a personal itch of mine, but never had enough
time to attack 
it. However, in around two months time I have a new project
needing the 
plugin, so I will be doing much work with it, certainly I
will be adding 
contracts to extract individual Photo's, probably a rating
app (write 
back to the meta-info file you are creating perhaps?),
outputting the 
photo's in a printable album and a few other triks.

I think the Photo Album may be the first true plugin to
emerge from the 
whiteboard at this rate (not counting the dispatcher as that
has always 
been intended as internal code).

Ross

> 
> Thanks again for the help on this...
> 
> --tim
> 
>