cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject NoClassDefFoundError after exception with J2 SDK 1.4.2_03
Date Wed, 17 Dec 2003 18:46:22 GMT
After upgrading to the 1.4.2_03 Java SDK I've noticed that Cocoon seems
to be getting NoClassDefFound errors on XMLConsumer after an exception
has been thrown.  I've seen this in two different ways with Cocoon 2.0.4
and Cocoon 2.1.3 and suspect it has something to do with the SDK.  Is
anyone else is running this version of the SDK (I'm on Win XP if that
makes a difference) and if so are you attempting to use
ExceptionSelector in the sitemap?  If so does it work?  We throw an
exception for session time out that should be caught by this selector
(and generate a logon screen) but instead we see a servlet exception
with a root cause as follows:

java.lang.NoClassDefFoundError: org/apache/cocoon/xml/XMLConsumer
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:1647)
        at java.lang.Class.getMethod0(Class.java:1893)
        at java.lang.Class.getMethod(Class.java:976)
        at
org.apache.commons.lang.exception.ExceptionUtils.getCauseUsingMethodName
(ExceptionUtils.java:278)
        at
org.apache.commons.lang.exception.ExceptionUtils.getCause(ExceptionUtils
.java:210)
        at
org.apache.commons.lang.exception.ExceptionUtils.getCause(ExceptionUtils
.java:178)
        at
org.apache.cocoon.selection.ExceptionSelector.find(ExceptionSelector.jav
a:165)
        at
org.apache.cocoon.selection.ExceptionSelector.getSelectorContext(Excepti
onSelector.java:154)
        at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invo
ke(SwitchSelectNode.java:130)
        at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
        at
org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNode.invo
ke(HandleErrorsNode.java:95)
        at
org.apache.cocoon.components.treeprocessor.sitemap.ErrorHandlerHelper.in
vokeErrorHandler(ErrorHandlerHelper.java:120)
        at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:189)
        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(TreePro
cessor.java:354)
        at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:260)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
        at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:246)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239
6)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:170)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469
)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
        at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1040)
        at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1151)
        at java.lang.Thread.run(Thread.java:534)

With Cocoon 2.0.3 I was attempting to catch the exception in my own
generator that then continued to output a SAX stream indicating the
session timeout and after upgrading the SDK I started seeing similar
behaviors...  The reason for posting here (instead of User) is that
given the pattern of this behavior I think the ExceptionSelector is
going to need to be reworked in order to work with the new SDK (although
backing off to an old version of the SDK may be a temporary solution at
least for us).

Peter Hunsberger



Mime
View raw message