You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "F.R. Da Costa Gomez" <dc...@fixed.com> on 2003/03/28 16:54:41 UTC
Tomcat & 2.4-a5
Hi,
Is anybody using 2.4-a5 with Tomcat 4.1.21 on a W2K box?
If so, what did you do with the commons-digester jar file?
I've tried it on two different boxes, to no avail! TC just doesn't
start up, so using the new a5 features is a no go for now.
Appreciating the fact that it looks like a TC vs digester issue I
thought it might also be of interest to those using Tapestry.
Esp. since it is about to fall under the Jakarta flag.
Fermin DCG
Error log:
10 [main] ERROR digester.Digester - Begin event threw exception
java.lang.ClassNotFoundException: org.apache.catalina.core.StandardServer
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:992)
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
at
org.apache.commons.digester.ObjectCreateRule.begin(ObjectCreateRule.java:252)
at org.apache.commons.digester.Rule.begin(Rule.java:200)
at org.apache.commons.digester.Digester.startElement(Digester.java:1268)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1543)
at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
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:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Catalina.start: java.lang.ClassNotFoundException:
org.apache.catalina.core.StandardServer
java.lang.ClassNotFoundException: org.apache.catalina.core.StandardServer
at
org.apache.commons.digester.Digester.createSAXException(Digester.java:2383)
at
org.apache.commons.digester.Digester.createSAXException(Digester.java:2409)
at org.apache.commons.digester.Digester.startElement(Digester.java:1271)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1543)
at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
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:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Re: Tomcat & 2.4-a5
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Sorry for the late reply, Mozilla mailbox problems, very boring indeed.
Hmm, I thought I had send a mail explaining what seemed to have happened
(oh well so much 4 hitech)
After fiddling with the whole thing for a couple of days I thought it
had something to do with the TC/server/lib as well.
The digester file also seems to reside in that dir. Which is fine by me
but does not explain why the whole thing has to fall over.
I'm not 100% on this because at 03:00h I tend to have my mind on
sleeping ;-) .
Long story short: it works and I'm working on putting my 1st app
together. Its working with a very nice and small embedded OODB (Perst)
that could possibly be something for an axample app as well (no beany
stuff or mapping issues, just extend from Persistent and of you go).
Howard M. Lewis Ship wrote:
>I'm unable to reproduce this problem.
>
>I installed on my computer (Windows XP, JDK 1.4) Tomcat 4.1.24.
>
>c:\workspace\jakarta-tapestry>ant -emacs deploy-tomcat
>Buildfile: build.xml
>
>check-for-tomcat-dir:
>
>deploy-tomcat:
>Expanding: C:\workspace\jakarta-tapestry\lib\workbench.war into C:\Program
>Files\Apache Group\Tomcat 4.1\webapps\workbench
>Copying 13 files to C:\Program Files\Apache Group\Tomcat
>4.1\webapps\workbench\WEB-INF\lib
>Copying 1 file to C:\Program Files\Apache Group\Tomcat
>4.1\webapps\workbench\WEB-INF\classes
>
>
>I then start and run Tomcat and can use everything in the Workbench no
>problems.
>
>Perhaps there's a bug in 4.1.21 that's fixed in 4.1.24?
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>
>
>
>
>
>>-----Original Message-----
>>From: F.R. Da Costa Gomez [mailto:dcg@fixed.com]
>>Sent: Friday, March 28, 2003 10:55 AM
>>To: Tapestry users
>>Subject: Tomcat & 2.4-a5
>>
>>
>>Hi,
>>
>>Is anybody using 2.4-a5 with Tomcat 4.1.21 on a W2K box?
>>If so, what did you do with the commons-digester jar file?
>> I've tried it on two different boxes, to no avail! TC just doesn't
>>start up, so using the new a5 features is a no go for now.
>>Appreciating the fact that it looks like a TC vs digester issue I
>>thought it might also be of interest to those using Tapestry.
>>Esp. since it is about to fall under the Jakarta flag.
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
>
>
>
>
RE: Tomcat & 2.4-a5
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
I'm unable to reproduce this problem.
I installed on my computer (Windows XP, JDK 1.4) Tomcat 4.1.24.
c:\workspace\jakarta-tapestry>ant -emacs deploy-tomcat
Buildfile: build.xml
check-for-tomcat-dir:
deploy-tomcat:
Expanding: C:\workspace\jakarta-tapestry\lib\workbench.war into C:\Program
Files\Apache Group\Tomcat 4.1\webapps\workbench
Copying 13 files to C:\Program Files\Apache Group\Tomcat
4.1\webapps\workbench\WEB-INF\lib
Copying 1 file to C:\Program Files\Apache Group\Tomcat
4.1\webapps\workbench\WEB-INF\classes
I then start and run Tomcat and can use everything in the Workbench no
problems.
Perhaps there's a bug in 4.1.21 that's fixed in 4.1.24?
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: F.R. Da Costa Gomez [mailto:dcg@fixed.com]
> Sent: Friday, March 28, 2003 10:55 AM
> To: Tapestry users
> Subject: Tomcat & 2.4-a5
>
>
> Hi,
>
> Is anybody using 2.4-a5 with Tomcat 4.1.21 on a W2K box?
> If so, what did you do with the commons-digester jar file?
> I've tried it on two different boxes, to no avail! TC just doesn't
> start up, so using the new a5 features is a no go for now.
> Appreciating the fact that it looks like a TC vs digester issue I
> thought it might also be of interest to those using Tapestry.
> Esp. since it is about to fall under the Jakarta flag.
>
Re: Tomcat & 2.4-a5
Posted by Stav <cc...@yahoo.com>.
This configuration works fine.
Just make sure that all the JARS that Tapestry
requires are in the workbench/WEB-INF/lib directory.
BTW: I only tested the workbench example.
In fact it works better on on 4.1 that on 3.3.x, where
I got a JSP error for some reason. Wasn't interested
enough to track it down.
Cheers.
--- "F.R. Da Costa Gomez" <dc...@fixed.com> wrote:
> Yep, but judging from your reaction you are probably
> getting different
> results.
> I'll do (yet) another install of TC after an
> uninstall of the current
> version and re-run the whole thing.
> It was indeed a clean install so I don't know about
> that (I'll just redo
> the whole thing to make sure).
>
> However, could the classpath have anything to do
> with the difference you
> reckon?
>
> Howard M. Lewis Ship wrote:
>
> >And you've tried this with a fresh, clean Tomcat
> install?
> >
> >I haven't had a chance to reproduce this.
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: Tomcat & 2.4-a5
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Yep, but judging from your reaction you are probably getting different
results.
I'll do (yet) another install of TC after an uninstall of the current
version and re-run the whole thing.
It was indeed a clean install so I don't know about that (I'll just redo
the whole thing to make sure).
However, could the classpath have anything to do with the difference you
reckon?
Howard M. Lewis Ship wrote:
>And you've tried this with a fresh, clean Tomcat install?
>
>I haven't had a chance to reproduce this.
>
>
RE: Tomcat & 2.4-a5
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
And you've tried this with a fresh, clean Tomcat install?
I haven't had a chance to reproduce this.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: F.R. Da Costa Gomez [mailto:dcg@fixed.com]
> Sent: Friday, March 28, 2003 12:22 PM
> To: Tapestry users
> Subject: Re: Tomcat & 2.4-a5
>
>
> Sorry for the length of the mail.
>
> I've tried it in the following ways.
> 1. Putting the required Tap jars in the TC appointed dir for
> apps using
> 'shared' jars. This is TC-HOME/common/lib. Have been doing this for
> quite a while without worries (significantly reduces war-file
> size as well).
> 2. Put the common-digester in the APP/WEB-INF/lib whilst using a4 is
> not a problem (though also quite useless)
> 3. TC-HOME/common/lib with the a5 jars & APP/WEB-INF/lib with the
> commons-digester and *code compiled* with the a4 library=>
> seems to work
> (how can I confirm this though?)
> 4. TC-HOME/common/lib with the a5 jars & APP/WEB-INF/lib with the
> commons-digester and *code compiled* with the a5 library=> Big trouble
> (output is below)
> 5. TC-HOME/common/lib WITHOUT the a5 jars & APP/WEB-INF/lib with the
> commons-digester + both a5 jars and *code compiled* with the a5
> library=> ERROR (as 4)
> 6. TC-HOME/common/lib WITHOUT ANY Tap jars & APP/WEB-INF/lib with the
> ALL the Tap jars and *code compiled* with the a5 library=>
> ERROR (as 4)
>
> Deploy by means of a war that contains all the app files and
> the commons
> digester in the above mentioned location. TC itself contains
> the rest of
> the jars.
> If I need to supply more info please lemme know.
>
> Following is a reply I got from the commons-digester list (maybe it
> means more to someone else):
> >>start mail <<
> It's impossible to know for sure without seeing your code,
> but I suspect
> you are running afoul of the problem that class loaders can
> only look *up*
> the class loader hierarchy, not *down*. For background info
> on how Tomcat
> sets up class loaders, see:
>
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-h
> owto.html
>
> So, the likely cause of your problem is that you're putting
> commons-digester.jar into $CATALINA_HOME/common/lib (so that
> it is in the
> common class loader) but trying to load a class from your webapp's
> /WEB-INF/classes or /WEB-INF/lib directories (in the webapp
> class loader).
> Because the digester classes are loaded from the former, they
> cannot see
> the latter.
>
> A straightforward workaround is to tell Digester to use the
> webapp class
> loader to load classes for things like the object create
> rule. As you're
> setting up your Digester instance, simply call:
>
> digester.setUseContextClassLoader(true);
>
> because the servlet container provides a thing called the
> "context class
> loader" and sets it to the one for your webapp.
> >> end mail <<
>
>
> =====================================================
> Error as thrown by Tomcat:
> =====================================================
> type Exception report
>
> message
> description The server encountered an internal error () that prevented
> it from fulfilling this request.
>
> exception
> javax.servlet.ServletException: Servlet.init() for servlet
> StdTapestryServlet threw exception
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardW
> rapper.java:963)
> at
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrap
> per.java:668)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.java:210)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.java:191)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContex
> t.java:2415)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:180)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDi
> spatcherValve.java:171)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:641)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:172)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:641)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java:174)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.
> java:223)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Process
> or.java:594)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle
> r.processConnection(Http11Protocol.java:392)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> nt.java:565)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:619)
> at java.lang.Thread.run(Thread.java:536)
>
> root cause
>
> java.lang.NoClassDefFoundError: org/apache/commons/digester/Digester
> at
> org.apache.tapestry.ApplicationServlet.parseApplicationSpecifi
> cation(ApplicationServlet.java:632)
> at
> org.apache.tapestry.ApplicationServlet.constructApplicationSpe
> cification(ApplicationServlet.java:525)
> at
> org.apache.tapestry.ApplicationServlet.init(ApplicationServlet
> .java:467)
> at
> org.dcg.platform.StdTapestryServlet.init(StdTapestryServlet.java:47)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardW
> rapper.java:935)
> at
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrap
> per.java:668)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.java:210)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.java:191)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContex
> t.java:2415)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:180)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDi
> spatcherValve.java:171)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:641)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:172)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:641)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java:174)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValv
> eContext.invokeNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:480)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.
> java:223)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Process
> or.java:594)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle
> r.processConnection(Http11Protocol.java:392)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> nt.java:565)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:619)
> at java.lang.Thread.run(Thread.java:536)
>
>
>
> Howard M. Lewis Ship wrote:
>
> >This is most concerning.
> >
> >Tomcat is supposed to have a complicated class loading
> structure just to
> >insulate applications from just this exact problem.
> >
> >How have you packaged your WAR file? Is digester & tapestry
> & etc. in
> >WEB-INF/lib? If you put the JARs in one of the global
> locations, you have a
> >greater chance for this kind of conflict.
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components
> >http://jakarta.apache.org/proposals/tapestry
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
Re: Tomcat & 2.4-a5
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Sorry for the length of the mail.
I've tried it in the following ways.
1. Putting the required Tap jars in the TC appointed dir for apps using
'shared' jars. This is TC-HOME/common/lib. Have been doing this for
quite a while without worries (significantly reduces war-file size as well).
2. Put the common-digester in the APP/WEB-INF/lib whilst using a4 is
not a problem (though also quite useless)
3. TC-HOME/common/lib with the a5 jars & APP/WEB-INF/lib with the
commons-digester and *code compiled* with the a4 library=> seems to work
(how can I confirm this though?)
4. TC-HOME/common/lib with the a5 jars & APP/WEB-INF/lib with the
commons-digester and *code compiled* with the a5 library=> Big trouble
(output is below)
5. TC-HOME/common/lib WITHOUT the a5 jars & APP/WEB-INF/lib with the
commons-digester + both a5 jars and *code compiled* with the a5
library=> ERROR (as 4)
6. TC-HOME/common/lib WITHOUT ANY Tap jars & APP/WEB-INF/lib with the
ALL the Tap jars and *code compiled* with the a5 library=> ERROR (as 4)
Deploy by means of a war that contains all the app files and the commons
digester in the above mentioned location. TC itself contains the rest of
the jars.
If I need to supply more info please lemme know.
Following is a reply I got from the commons-digester list (maybe it
means more to someone else):
>>start mail <<
It's impossible to know for sure without seeing your code, but I suspect
you are running afoul of the problem that class loaders can only look *up*
the class loader hierarchy, not *down*. For background info on how Tomcat
sets up class loaders, see:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html
So, the likely cause of your problem is that you're putting
commons-digester.jar into $CATALINA_HOME/common/lib (so that it is in the
common class loader) but trying to load a class from your webapp's
/WEB-INF/classes or /WEB-INF/lib directories (in the webapp class loader).
Because the digester classes are loaded from the former, they cannot see
the latter.
A straightforward workaround is to tell Digester to use the webapp class
loader to load classes for things like the object create rule. As you're
setting up your Digester instance, simply call:
digester.setUseContextClassLoader(true);
because the servlet container provides a thing called the "context class
loader" and sets it to the one for your webapp.
>> end mail <<
=====================================================
Error as thrown by Tomcat:
=====================================================
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet
StdTapestryServlet threw exception
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:963)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
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.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
root cause
java.lang.NoClassDefFoundError: org/apache/commons/digester/Digester
at
org.apache.tapestry.ApplicationServlet.parseApplicationSpecification(ApplicationServlet.java:632)
at
org.apache.tapestry.ApplicationServlet.constructApplicationSpecification(ApplicationServlet.java:525)
at
org.apache.tapestry.ApplicationServlet.init(ApplicationServlet.java:467)
at org.dcg.platform.StdTapestryServlet.init(StdTapestryServlet.java:47)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
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.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
Howard M. Lewis Ship wrote:
>This is most concerning.
>
>Tomcat is supposed to have a complicated class loading structure just to
>insulate applications from just this exact problem.
>
>How have you packaged your WAR file? Is digester & tapestry & etc. in
>WEB-INF/lib? If you put the JARs in one of the global locations, you have a
>greater chance for this kind of conflict.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/proposals/tapestry
>
>
RE: Tomcat & 2.4-a5
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
This is most concerning.
Tomcat is supposed to have a complicated class loading structure just to
insulate applications from just this exact problem.
How have you packaged your WAR file? Is digester & tapestry & etc. in
WEB-INF/lib? If you put the JARs in one of the global locations, you have a
greater chance for this kind of conflict.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: F.R. Da Costa Gomez [mailto:dcg@fixed.com]
> Sent: Friday, March 28, 2003 10:55 AM
> To: Tapestry users
> Subject: Tomcat & 2.4-a5
>
>
> Hi,
>
> Is anybody using 2.4-a5 with Tomcat 4.1.21 on a W2K box?
> If so, what did you do with the commons-digester jar file?
> I've tried it on two different boxes, to no avail! TC just doesn't
> start up, so using the new a5 features is a no go for now.
> Appreciating the fact that it looks like a TC vs digester issue I
> thought it might also be of interest to those using Tapestry.
> Esp. since it is about to fall under the Jakarta flag.
>
> Fermin DCG
>
> Error log:
> 10 [main] ERROR digester.Digester - Begin event threw exception
> java.lang.ClassNotFoundException:
> org.apache.catalina.core.StandardServer
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(Stand
> ardClassLoader.java:992)
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(Stand
> ardClassLoader.java:857)
> at
> org.apache.commons.digester.ObjectCreateRule.begin(ObjectCreat
> eRule.java:252)
> at org.apache.commons.digester.Rule.begin(Rule.java:200)
> at
> org.apache.commons.digester.Digester.startElement(Digester.java:1268)
> at
> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStar
> tElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatche
> r.scanRootElementHook(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$Fragment
> ContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocu
> ment(Unknown
> Source)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.commons.digester.Digester.parse(Digester.java:1543)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
> Catalina.start: java.lang.ClassNotFoundException:
> org.apache.catalina.core.StandardServer
> java.lang.ClassNotFoundException:
> org.apache.catalina.core.StandardServer
> at
> org.apache.commons.digester.Digester.createSAXException(Digest
> er.java:2383)
> at
> org.apache.commons.digester.Digester.createSAXException(Digest
> er.java:2409)
> at
> org.apache.commons.digester.Digester.startElement(Digester.java:1271)
> at
> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStar
> tElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatche
> r.scanRootElementHook(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$Fragment
> ContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocu
> ment(Unknown
> Source)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.commons.digester.Digester.parse(Digester.java:1543)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>