> What you mentioned is correct. But, for my case, the only controller
servlet code
> has been recompiled; no supporting classes have been changed or
recompiled. --
> Laiwu
>
i would like to point u to the readme file included in the distribution...
here is a small piece from it:
-- readme -- $TOMCAT_HOME/doc/readme --
Tomcat 3.1 includes a new feature whereby you can ask it to automatically^M
reload servlet classes (loaded from either the WEB-INF/classes directory^M
or a JAR file in the WEB-INF/lib directory) that have been changed. This^M
feature is experimental, and may not be completely functional. In
particular,^M
changes to classes other than the servlet you are requesting do not
trigger^M
class reloads -- you will need to restart Tomcat to reflect changes in
those^M
classes.
Reloading is enabled by including a reloadable="true" attribute on the^M
<Context> element in the "conf/server.xml" file. Note that automatic^M
reload support is not recommended for production applications because of^M
its experimental nature, and the extra overhead required to perform the^M
necessary checks on every request.^M
---
i dont know exactly what problem u might be facing, but now u have someone
to blame :)
parag.
> Parag V Thakur wrote:
>
> > > We are following model 2 architecture to develop an application on
> > > Tomcat3.1 server. But we encounter a problem whenever we recompile the
> > > controller servlet code, we have to restart Tomcat server; otherwise,
> > > JSP page will get "java.lang.ClassCastException" which relates to the
> > > code we use to cast a java bean after retrieved it from session object
> > > inside JSP code. (By the way, we have edited the "conf/server.xml"
file
> > >
> > > so that the application codes are reloadable.)
> >
> > my belief is that the reloadable attribute just ensures reloading of a
> > servlet if it's changed (it happens when the user tries to access that
> > servlet). It does not reload any supporting classes if they have
changed. So
> > i guess, u will HAVE to restart the servlet engine everytime u change
the
> > supporting classes.
> >
> > parag.
> >
> > >
> > > We are anxious to know if anyone encounter the similar problem and how
> > > to solve it.
> > >
> > > Thanks,
> > >
> > > --
> > > Laiwu Luo
> > >
> > >
> >
===========================================================================
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST".
> > > Some relevant FAQs on JSP/Servlets can be found at:
> > >
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
> >
===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
