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