Re[2]: (Servlet Reloading) (Was Am I in the right list?)

[Jonathan Pierce <Jo...@seagram.com>]

Craig,

I see no reason why we shouldn't  pursue class reloading.  Perhaps we should
only reload classes that were loaded from lib jar files.

Each servlet can maintain its classes in its own package, so classes could be
reloaded whenever the jar file that loaded the servlet changed. This shouldn't
be too much overhead.

Servlets will however get class cast exceptions if they include in their jar
files library classes which are shared by other servlets since the other servlet
jar files may not have changed.

Just because it is difficult to implement, doesn't mean Tomcat shouldn't include
it as an feature that can be explicitly enabled or disabled. I can contribute
some servlet loader code that I wrote if needed.

-Jonathan

____________________Reply Separator____________________
Subject:    Re: Am I in the right list?
Author: general@jakarta.apache.org
Date:       11/18/99 4:55 PM

Joseph Shelby wrote:

> "Craig R. McClanahan" wrote:
> > Auto-reloading of changed servlet classes would be better characterized as a
> > missing feature, rather than a bug.
> >
> > What's going on is that, the first time you access a servlet, it's class
file
> > gets loaded in to the JVMs memory.  From then until you shut down Tomcat,
> > anything that happens to the original class file (you can even delete it) is
> > ignored, because the in-memory copy is being used.  This is true for Java in
> > general, not just for servlets.
>
> ok, why the change?

What change?  Jakarta Tomcat has never supported this feature.

>  i figured the alternative (reloading the class
> if the .class file changed) would have been the harder thing to do
> (since its not the default by my understanding of the standard jvm
> as provided by sun and blackdown).  I know JServ does it the other
> way, and i was pretty sure tomcat _used_ to do it the other way...
>

Nope.  Tomcat (even in its earlier incarnations inside JSWDK and JSDK) has not
ever
had this feature.  You might be thinking about JWS, though, which is a product
not
a reference implementation.

As our experience with Apache JServ showed (I'm one of the developers),
implementing class reloading is incredibly complicated.  The semantics of the
JVM
force you to throw away the old class loader (and therefore all classes loaded
by
that class loader, and all object instances of these classes) in order to pull
this
off.  Doing this without disrupting an ongoing application, and without causing
class cast exceptions later, is quite a trick.

>
> is it just 'cause the re-checking is slowing it down too much?
>
> i would rather that be a configuration option -- i like having instant
> feedback when i change a .jsp file...killing the jvm and restarting it
> for every _minor_ .jsp change is a real hassle during development time...
>

Note:  Tomcat *does* support reload checking on JSP pages -- not on servlets. 
When
it detects an updated JSP page it does not unload the old class; instead, it
generates a new class and starts using that instead.  It can do this because the
JSP container owns the class name of the implementation of a page -- servlet
containers do not have that luxury.

>
> joe
>

Craig McClanahan



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re[2]: (Servlet Reloading) (Was Am I in the right list?)

[Martin Koistinen <ma...@koistinen.com>]

(Strange, I seem to only be getting some of these messages and not others...)

My experience with this version is that it IS re-loading sometimes.  While 
I develop, I test, code more, retest and things were going pretty smooth 
until it stopped taking my changes.

FYI.

-- Martin

At 08:13 PM 11/18/99 -0500, you wrote:
>Craig,
>
>I see no reason why we shouldn't  pursue class reloading.  Perhaps we should
>only reload classes that were loaded from lib jar files.
>
>Each servlet can maintain its classes in its own package, so classes could be
>reloaded whenever the jar file that loaded the servlet changed. This shouldn't
>be too much overhead.
>
>Servlets will however get class cast exceptions if they include in their jar
>files library classes which are shared by other servlets since the other 
>servlet
>jar files may not have changed.
>
>Just because it is difficult to implement, doesn't mean Tomcat shouldn't 
>include
>it as an feature that can be explicitly enabled or disabled. I can contribute
>some servlet loader code that I wrote if needed.
>
>-Jonathan
>
>____________________Reply Separator____________________
>Subject:    Re: Am I in the right list?
>Author: general@jakarta.apache.org
>Date:       11/18/99 4:55 PM
>
>Joseph Shelby wrote:
>
> > "Craig R. McClanahan" wrote:
> > > Auto-reloading of changed servlet classes would be better 
> characterized as a
> > > missing feature, rather than a bug.
> > >
> > > What's going on is that, the first time you access a servlet, it's class
>file
> > > gets loaded in to the JVMs memory.  From then until you shut down Tomcat,
> > > anything that happens to the original class file (you can even delete 
> it) is
> > > ignored, because the in-memory copy is being used.  This is true for 
> Java in
> > > general, not just for servlets.
> >
> > ok, why the change?
>
>What change?  Jakarta Tomcat has never supported this feature.
>
> >  i figured the alternative (reloading the class
> > if the .class file changed) would have been the harder thing to do
> > (since its not the default by my understanding of the standard jvm
> > as provided by sun and blackdown).  I know JServ does it the other
> > way, and i was pretty sure tomcat _used_ to do it the other way...
> >
>
>Nope.  Tomcat (even in its earlier incarnations inside JSWDK and JSDK) has not
>ever
>had this feature.  You might be thinking about JWS, though, which is a product
>not
>a reference implementation.
>
>As our experience with Apache JServ showed (I'm one of the developers),
>implementing class reloading is incredibly complicated.  The semantics of the
>JVM
>force you to throw away the old class loader (and therefore all classes loaded
>by
>that class loader, and all object instances of these classes) in order to pull
>this
>off.  Doing this without disrupting an ongoing application, and without 
>causing
>class cast exceptions later, is quite a trick.
>
> >
> > is it just 'cause the re-checking is slowing it down too much?
> >
> > i would rather that be a configuration option -- i like having instant
> > feedback when i change a .jsp file...killing the jvm and restarting it
> > for every _minor_ .jsp change is a real hassle during development time...
> >
>
>Note:  Tomcat *does* support reload checking on JSP pages -- not on servlets.
>When
>it detects an updated JSP page it does not unload the old class; instead, it
>generates a new class and starts using that instead.  It can do this 
>because the
>JSP container owns the class name of the implementation of a page -- servlet
>containers do not have that luxury.
>
> >
> > joe
> >
>
>Craig McClanahan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org