Actually it doesn't have anything to do with timestamps. Class equivalence in Java is
based on the class and the class loader. Think
of the class loader id as a prefix for the class's name to give a completely qualified
class name.
All this behaviour rises from the way servlet engines spawn new class loaders to
handle class reloading.
Because of this (and other problems) I generally don't like/use class reloading except
for use with very simple servlets.
I just have Apache and the servlet engine set up on my development system and I
restart as appropriate.
There is a fairly elegant work around to the whole issue that involves programming to
interfaces. (Elegant in that it works with the
design of the language and is portable across servlet engines - can be quite a bit
more work) Just define all your classes as
packages of interfaces and put the interfaces in your system class path. Then write
your servlets that so they use the interfaces
and not the class names. Now when class reloading occurs your casts (to interfaces)
will still work because the interface didn't
change.
Note:
I find the interface scheme to be only helpful when you have to rely on class
reloading in a production environment.
The objects stored in sessions won't exhibit the new behaviour. They will still be
using the older definition of the class so you'll
still have to generate a new session (stop and start your browser) to test your
changes.
HTH
> Did you guys notice that the problem goes away when you restart Tomcat?
> I posted this earlier, but I found this problem due to rebuilding
> classes while Tomcat is running and then the classes have different
> time stamps from the ones already loaded on Tomcat.
>
> If you restart Tomcat after making changes, see if everything works?
***********************************************************
Brett Knights 250-338-3509 work
[EMAIL PROTECTED] 250-334-8309 home
***********************************************************
