Well, if that's the way it's designed, I guess I can live with it too, but
it does seem a bit restrictive.
From the messages I've read on Tomcat 4, it seems a LOT of effort has gone
into making it reload classes when they're changed, so I don't really see
the point of it, if we're going to resign to restarting the server anyway.
What's the point of the 'reload' function of the Tomcat 'manager'? It
doesn't do what (it seems to me) it should do, which is restart the app,
just as if the server had been started afresh.
To answer your question, I just copied the WAR file into tomcat/webapps and
let it be deployed automatically. Does that make a difference?
Cheers,
Simon.
At 12:23 PM 5/11/01 -0700, Anthony Martin wrote:
>Keep your precious hair. I'm pretty sure Struts and Tomcat are operating as
>designed.
>
>I noticed this when I first started working with Struts too, and it caused
>me about thirty minutes of horrible pain and suffering until I realized that
>restarting the server is required due to the nature of the framework. To
>me, it seems reasonable to restart Tomcat every time a class gets
>recompiled.
>
>I try to make sure my code is pretty solid before testing moving on to
>testing. I admit, after being a scripter for a few years (perl, later php),
>I felt a little restricted by this. But like any compiled language and even
>when scripting, it's best to avoid the code-compile-test-repeat routine if
>you can because ... it is bad.
>
>When you say that you installed the struts-example, did you deploy the .war
>like the manual suggests, or did you extract it manually?
>
>
>Anthony
>
>-----Original Message-----
>From: Simon Wawra [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 11, 2001 10:50 AM
>To: [EMAIL PROTECTED]
>Subject: struts and tomcat4 reload causes exception
>
>
>Hi,
>
>It sounds like this topic's been pretty exhaustively covered on the mailing
>list, but I haven't yet seen a solution to it, so sorry for dragging it up
>again. I'm pretty sure I've read every message on the list on this topic...
>
>I'm having seriously difficulty getting my webapp, which is based on struts
>to reload after I make changes to the source.
>
>I initially started encountering errors with Tomcat 3.3, when I recompiled
>any of my classes the next request would generate an exception. It would
>continue to generate exceptions until I completely restarted tomcat. At
>least it seemed that Tomcat was properly detecting the changes though...
>
>Now I'm running the just-released Tomcat 4 Beta 4, and the 11 May (today's)
>build of Struts and I have exactly the same problem:
>
>A Servlet Exception Has Occurred
>java.lang.ClassCastException: org.apache.struts.action.ActionMappings
>
>(see below for full stacktrace). (I've also tried Tomcat 4 Beta 1 with
>Struts 1 Beta 1).
>
>I'm pretty new to JSP and struts myself, but I am fairly sure that Struts
>itself is having problems reloading. The errors are always from struts
>classes. My app works perfectly until I change a class or 'force' a reload
>using Tomcat 4's manager feature. Calling the reload feature of struts
>makes no difference either.
>
>I'm fairly sure it's not my code, because I installed the struts-example
>app, and if I force a reload of that app (using tomcat manager again), I
>get the same kind of errors. The index.jsp page crashes it with this
>message:
>
>javax.servlet.ServletException: Cannot find message resources under key
>org.apache.struts.action.MESSAGE
>
>Surely the example app must work properly? Perhaps I've just messed up the
>configuration? Any tips that can help me would me most grateful (as well
>as saving my hair...)
>
>Thanks in advance,
>
>Simon.
>---
>
>Here's the stack trace:
>
>A Servlet Exception Has Occurred
>java.lang.ClassCastException: org.apache.struts.action.ActionMappings
> at org.apache.struts.taglib.html.FormTag.lookup(FormTag.java:766)
> at
>org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:481)
> at org.apache.jsp.login_jsp._jspService(login_jsp.java:141)
> at
>org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
>va:200)
> at
>org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
> at
>org.apache.jasper.servlet.JspServlet.service(JspServlet.java:453)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
>FilterChain.java:254)
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
>ain.java:194)
> at
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
>va:255)
> at
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
> at
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
>org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
>va:225)
> at
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
> at
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
>org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
> at
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
>)
> at
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
> at
>org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
> at
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>64)
> at
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
>org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
>:163)
> at
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
> at
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
>org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
>875)
> at
>org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
> at java.lang.Thread.run(Thread.java:479)
>
>
>
>
>
>---
>TMC Technology & Management Consulting
>
>+41 (0)22 365 4712
>Mailto:[EMAIL PROTECTED]
---
TMC Technology & Management Consulting
+41 (0)22 365 4712
Mailto:[EMAIL PROTECTED]
