tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Parker" <rand...@nls.net>
Subject Re: Servlet reloading?
Date Sat, 12 Feb 2000 22:41:38 GMT
Sam,

The ability to do incremental compilation while debugging has proven to be quite useful to

myself and many others. Servlet reloading can be thought of as a less fine grained version
of 
incremental compilation. Instead of incrementally compiling a method a whole class gets 
recompiled. 

In many testing scenarios one has to load a large number of classes and go thru a lot of steps

to get to, say, a particular servlet whose response to a particular situation you want to
test. 
This can be time-consuming and make the test loop lengthy.

Therefore the ability to debug thru that servlet, see a change that needs to be made, make
the 
change, and reload its code without having to reload and repeat all the steps is highly useful.

So, IMO, if one restricts oneself purely to development environments then the ability to do

reloads of changed classes is really useful. 

In a more refined version of this feature I'd like to be able to tell it to pop up a control
panel or 
run some script that tells it just to reload a particular single class or particular set of
classes, 
rather than all the classes with later time-stamps.

One other thing: I'd already like a special class loader for use in development environments
that 
are not file-oriented. In particular, I'd to get servlets loading off a class path (not necessarily
the 
system classpath environment variable) that does not use the WEB-INF directory as part of
its 
pathing.

On Sat, 12 Feb 2000 16:53:12 -0500, rubys@us.ibm.com wrote:

>3.  Stateful restart - changes incorporated into live system
>
>    I have difficultly imaging the use case for this one.
>
>    On one hand, I certainly admire the technical solution
>    to a quite difficult problem.  And perhaps someone can
>    argue this is needed for sites which can tolerate
>    absolutely no down time.
>
>    On the other hand, being basically distrustful, I know I
>    wouldn't want to open myself up to the possibility of an
>    incomplete restore on a production site - however rare this
>    may be.  Nor would I want to deal with the uncertainty
>    while debugging.



Mime
View raw message