Harald Wehr wrote:
Thanks for your fast answer. I tested your hints but that didn't help. Nevertheless there is an interesting debug output. If I call conn.getClass().getName() to the connection I get from the pool, the output is:
------------
$Proxy4
------------
Looks to me like Excalibur is wrapping the class in a dynamic proxy
which is then leading to the class cast exception. Unfortunately, I
don't know whether you're supposed to find an abstracted api within
excalibur datasource for the feature you want (which seemed to be
hinted at by Bertrand's answer, or if "fixing" the proxy is what is needed, or if this is just a good old fashioned bug or unimplemented
feature.
I seem to recall that excalibur was using the dynamic proxies in order to get around JDK 1.3/1.4 differences in jdbc. So, my guess is you are
using JDK 1.3? If so, perhaps switching to 1.4 would make the proxy unnecessary and would be a workaround.
I'm already working with JDK 1.4.2, so this can't be an issue here.
BTW, what does the stack trace say besides ClassCastException?
Here is the full stack trace:
java.lang.ClassCastException
at de.hsharz.vrgis.cocoon.SVGGenerator.getVector(SVGGenerator.java:68)
at de.hsharz.vrgis.cocoon.SVGGenerator.convert(SVGGenerator.java:135)
at de.hsharz.vrgis.cocoon.SVGGenerator.generate(SVGGenerator.java:336)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:549)
at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:501)
at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:163)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:354)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1723)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1673)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:783)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:945)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:800)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454)
Harald
