Problem updating class files

Re: Problem updating class files

"Harold Ensle" <[email protected] com.com> wrote in message news:<Z_5Eb.888 1$0s2.8112@news read2.news.pas. earthlink.net>. ..[color=blue]
> Has anyone ever had this problem? I have been compiling servlet files,
> correcting them, recompiling them and seeing the changes on the
> next URL request. So everything was going smoothly. Suddenly
> I could no longer change the .class files. That is, they were changed
> but the URL was apparently calling a cached version which would
> not update. When Apache was restarted, it would then finally update.
> Needless to say this is very undesirable behavior and its sudden
> mysterious appearance is very puzzling. (To prove that it was a
> cached version, I deleted all copies of both the class and java
> files from the server and the URL call still worked!...until apache
> was restarted.)
>
> H.Ellis Ensle[/color]


A servlet's class files are never transmitted. Therefore, if they are
cached, it is the servlet container that is doing the caching. It
doesn't make sense not to cache the class files and keep them loaded
because in a production environment requests come in more often than
the class files are changed.

Since you mentioned apache, I'm going to assume you are using the
Apache tomcat servlet container. Tomcat has settings which dictate
whether it should check the class files each time a request comes in
or not to. In the latter case, you will have to reload the servlet
either by using the manager interface or by restarting the server.

If you are using a connector through to the Apache HTTPD server,
restarting the http server will have no effect on the state of the
servlet.

---
Jared Dykstra

Re: Problem updating class files


"Jared Dykstra" <dyksjare@hotma il.com> wrote in message
news:ba84b53e.0 312181522.7bd69 [email protected] gle.com...[color=blue]
> "Harold Ensle" <[email protected] com.com> wrote in message[/color]
news:<Z_5Eb.888 1$0s2.8112@news read2.news.pas. earthlink.net>. ..[color=blue][color=green]
> > Has anyone ever had this problem? I have been compiling servlet files,
> > correcting them, recompiling them and seeing the changes on the
> > next URL request. So everything was going smoothly. Suddenly
> > I could no longer change the .class files. That is, they were changed
> > but the URL was apparently calling a cached version which would
> > not update. When Apache was restarted, it would then finally update.
> > Needless to say this is very undesirable behavior and its sudden
> > mysterious appearance is very puzzling. (To prove that it was a
> > cached version, I deleted all copies of both the class and java
> > files from the server and the URL call still worked!...until apache
> > was restarted.)
> >
> > H.Ellis Ensle[/color]
>
>
> A servlet's class files are never transmitted. Therefore, if they are
> cached, it is the servlet container that is doing the caching. It
> doesn't make sense not to cache the class files and keep them loaded
> because in a production environment requests come in more often than
> the class files are changed.
>
> Since you mentioned apache, I'm going to assume you are using the
> Apache tomcat servlet container. Tomcat has settings which dictate
> whether it should check the class files each time a request comes in
> or not to. In the latter case, you will have to reload the servlet
> either by using the manager interface or by restarting the server.
>
> If you are using a connector through to the Apache HTTPD server,
> restarting the http server will have no effect on the state of the
> servlet.[/color]


Yes, I discovered the problem. I inadvertantly put the servlet directory
in the classpath (listed it in the properties file). This caused it not to
check
for new files, so it never updated the cache. I was surprised because I
never thought that any configuration would ignore the class file on disk.
But I guess it is sometimes desirable to do so for performance reasons.

H.Ellis Ensle