Re: Objects in Vector are loosing type

[Endre Stølsvik <En...@Stolsvik.com>]

On Mon, 30 Apr 2001, Joel Parramore wrote:

|
| Can or has or will someone work up a slightly more technical explanation
| than
|
| > It's because tomcat's reloading are totally fucked.

Well, Joel, it's because tomcat3x doesn't do this:

a) stop the webapp
b) destroys all servlets
c) serializes all the Sessions
d) throws away the ClassLoader for this webapp
e) cleans away the webapp from all "caches" in the system
f) restarts the whole webapp, as if for the first time, making a new
    ClassLoader for it.
g) deserializes all the Sessions (now with the new ClassLoader)
h) lets the users use the system again

(Which is apparently how tomcat 4 should do it, but it never did for me.
But I am doing a very weird ting according to the developers, I am running
tomcat away from it's installation directory, and this is _not_
supported.)

What tomcat3x does, is to just ditches the ClassLoader and reloads the
_first_ servlet you hit after a refresh of the .class-files timestamps.
Even if you recompile your whole webapp, tomcat just reloads the first
servlet a user hits. This means that all the other Servlets are still
"cached" using the old ClassLoader, and you actually get two instanses of
your webapp, all the old Session objects and all the other Servlets loaded
with the old ClassLoader, while all the new Session objects and the one,
first hit Servlet with the new ClassLoader.
  It doesn't, as mentioned, do anything about the Session variables, and
therefore you often get ClassCastExceptions when you try to handle and
cast objects gotten from the Session within the one, new reloaded servlet.
This because _it's_ version of the Class you try to cast the object gotten
from the Session to, is loaded with the new ClassLoader, while the object
you try to cast is loaded with the old. This is not considered the same
Classes, and you get ClassCastException.

This is so very, very wrong, and therefore I'd say it's "totally fucked"..
This has been pointed out a whole bunch of times.

Better? I'm not that fantastic with English, hope you excuse that, Joel.

Endre.

Re: Objects in Vector are loosing type - classload problems

[David Wall <dw...@myEastside.com>]

> I have to restart tomcat each and every time I make one single change to
> _anyting_ of my code. This is the most time consuming part of developing
> on Tomcat, I feel. (How's Jetty doing, btw??)

Of course, you are free to use any implementation, or you could even submit
an example of how to fix it.

Personally, I think the classloader scheme itself is rather broken, which
apparently is why there are so many problems.  It seems absurd to me that
the classloader "hierarchy" only allows you to go UP, but now down.  We've
seen this problem so many times, such as when using JMS and wanting to put
the JMS files in a base classloader (like on the CLASSPATH) or JCE/JNDI code
that may be loaded in the initial classloaders because they are defined in
lib/ext or in java.security properties file.  If you call those libraries
and they need to serialize your object or anything, they can't do it because
your object was probably created using the classloader created by the Tomcat
context.  I can see that the first check for a class should be in the
current classloader, then it can move its way up the hierarchy to the top
level classloader, but if it's not found, it would be great if it could then
start to look DOWN the hierarchy to see if it can find it.  I suspect
there's some odd security reason not to do this, but it seems unlikely since
you first give the system the ability to look up the chain and only go down
if it's not found.

But Tomcat 4.0 was supposed to fix things, but my quick test shows there are
still problems keeping the classloaders all separated.  When I run two
virtual host contexts in the same Tomcat instance, and both contexts make
use of JMS, JNDI, JDBC and JCE, there's always a conflict that makes it not
work (like static/singleton instances being created under one context being
"reused" in the other context).  By putting them in separate Tomcats,
everything works.  So, there's either a longstanding bug in the Tomcat 3.2
and 4.0 classloader scheme, or there's a basic conflict in the behavior of
classloaders that is really not workable.  This probably gets even worse in
EJB worlds, but I'm not sure.

David

Re: Objects in Vector are loosing type

[Milt Epstein <me...@uiuc.edu>]

On Fri, 4 May 2001, Endre Stølsvik wrote:

> On Thu, 3 May 2001, Milt Epstein wrote:
>
> | Maybe your app could use some reorganizing.
>
> Yeah, maybe, Milt.
>
> Why don't you ask the developers, then? I actually believe that all
> things I said in those mails about reloading in TC3.x and TC4 are
> correct.

Because I have no reason to.  I have had success with reloading with
3.2.1 (and so have others, as reported on the list) -- so I don't
think all your comments were accurate.  I believe that includes
changes to auxiliary, non-servlet classes, but I don't recall exactly.
Next time I have occasion to try, I'll report the results (if I
remember :-).  I have heard that reloading with 4.X is more
problematic (and may not work at all), but I haven't tried it yet
myself.

I did at one time have problems with ClassCastExceptions (and similar,
having to do with native code), but with a little bit of reorganizing,
I was able to get around it.  (Admittedly my apps are not the most
complex, nor do I currently make extensive use of objects in sessions.)


> And the reason for me having to restart every time is that I
> basically have made a "server" running "on top of tomcat", and
> there's basically only 3 servlets running, but with lots of helper
> classes and stuff around.
>
> The reason for _always_ getting a ClassCastException is that I have
> all my user information stored in a User object. This won't ever
> reload (that is, serialize/deserialize, or in some other way being
> "cast" over to the new classloader), and when i retrieve it from the
> HttpSession, it's _always_ ClassCastException'ing.
>
> I'm not the only one making such "complicated" apps. The exact same
> story about the "User object" have been mentioned a couple of times
> on this list.

Likely true.  And I'm sure if it was happening to me (and it may in
the future :-), I'd be annoyed as well.  And, FWIW, servlet reloading
seems a more straightforward thing that should be working -- handling
all the ClassCastExceptions seems a more complex issue (although if
what you say is true, and is the norm, having plain servlet reloading
without handling the ClassCastException issues won't do some people
any good).

The thing that bothered me is that you were ranting and raving about
the problems without a deep technical understanding of the issues,
without appreciation for what the tomcat developers have done, and
without offering to contribute.  Tomcat is not a commercial product
where you should be expecting (and/or demanding) more.  The developers
may be sticking to more "core" features that they need to get working
to implement the spec (I believe reloading is not part of the spec).

Have you tried checking out the tomcat-dev list to see what they have
to say about it there?  Seems that would be more constructive.

Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu

Re: Objects in Vector are loosing type

[Endre Stølsvik <En...@Stolsvik.com>]

On Thu, 3 May 2001, Milt Epstein wrote:

| Maybe your app could use some reorganizing.

Yeah, maybe, Milt.

Why don't you ask the developers, then? I actually believe that all things
I said in those mails about reloading in TC3.x and TC4 are correct.

And the reason for me having to restart every time is that I basically
have made a "server" running "on top of tomcat", and there's basically
only 3 servlets running, but with lots of helper classes and stuff around.

The reason for _always_ getting a ClassCastException is that I have all my
user information stored in a User object. This won't ever reload (that is,
serialize/deserialize, or in some other way being "cast" over to the new
classloader), and when i retrieve it from the HttpSession, it's _always_
ClassCastException'ing.

I'm not the only one making such "complicated" apps. The exact same story
about the "User object" have been mentioned a couple of times on this
list.

And that's how it is.

;)


-- 
Mvh,
Endre

Re: Objects in Vector are loosing type

[Milt Epstein <me...@uiuc.edu>]

On Thu, 3 May 2001, Endre Stølsvik wrote:

> On Wed, 2 May 2001, Joel Parramore wrote:
>
> | Well, Endre, comments such as "classloading is totally fucked",
> | while having a nice kewl sound-bite quality, really don't explain
> | what is going on too well to someone who hasn't encountered the
> | problem before.
>
> It's just that it kind of annoys me. It's definately an huge itch,
> but I don't have the time to scratch it. Stupid thing to say, but
> what's annoying is that it's not quite recongized by the developers
> as a problem, which truly puzzles me..

How do you know they don't consider it a problem?  Maybe it's not as
easy to solve as you think it is.  Or maybe there are other things
they consider higher priority.  Maybe you can contribute some time and
code the solution yourself.


> I have to restart tomcat each and every time I make one single
> change to _anyting_ of my code. This is the most time consuming part
> of developing on Tomcat, I feel. (How's Jetty doing, btw??)

*Every* time, for any change?  That doesn't sound right.  Servlet
reloading works for me (I'm using Tomcat 3.2.1).  The
classloader/class cast issue is different than simple reloading of
servlets.


> Also, forgot to mention, the reloader doesn't notice if any _other_
> classes have changed, e.g. your User object or whatever. Only the
> directly affected Servlet, and only the first one hit, will get
> reloaded.
[ ... ]

I don't believe this is correct either -- for classes that are in the
servlet directories (as opposed to the classpath), I believe reloading
works.

Maybe your app could use some reorganizing.

Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu

Re: Objects in Vector are loosing type

[Endre Stølsvik <En...@Stolsvik.com>]

On Wed, 2 May 2001, Joel Parramore wrote:

|
| Well, Endre, comments such as "classloading is totally fucked", while having
| a nice kewl sound-bite quality, really don't explain what is going on too
| well to someone who hasn't encountered the problem before.

It's just that it kind of annoys me. It's definately an huge itch, but I
don't have the time to scratch it. Stupid thing to say, but what's
annoying is that it's not quite recongized by the developers as a problem,
which truly puzzles me..

I have to restart tomcat each and every time I make one single change to
_anyting_ of my code. This is the most time consuming part of developing
on Tomcat, I feel. (How's Jetty doing, btw??)

Also, forgot to mention, the reloader doesn't notice if any _other_
classes have changed, e.g. your User object or whatever. Only the directly
affected Servlet, and only the first one hit, will get reloaded.

If not totally fucked, it's definately pretty messed up..!

;)

Endre

RE: Objects in Vector are loosing type

[Joel Parramore <pa...@homes.com>]

Well, Endre, comments such as "classloading is totally fucked", while having
a nice kewl sound-bite quality, really don't explain what is going on too
well to someone who hasn't encountered the problem before.

Speaking for myself, I had not seen any sort of explanation on the mailing
list before (haven't done an extensive archive check, admittedly, esp. on
the developer list), nor in the Jakarta FAQs.  Another poster commented that
this item keeps popping up; perhaps making this into a FAQ item would insure
that questions and comments on the topic would assist in preventing this
question from (re)occuring.  (Perhaps a weekly posting of FAQ items would
help as well, but that's another issue.)

Thanks for the explanation, though.  And your English is just fine. :-)

Regards,
Joel Parramore



> -----Original Message-----
> From: Endre Stolsvik [mailto:Endre@Stolsvik.com]
> Sent: Wednesday, May 02, 2001 2:53 AM
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Objects in Vector are loosing type
>
>
> On Mon, 30 Apr 2001, Joel Parramore wrote:
>
> |
> | Can or has or will someone work up a slightly more technical explanation
> | than
> |
> | > It's because tomcat's reloading are totally fucked.
>
> Well, Joel, it's because tomcat3x doesn't do this:
>
> a) stop the webapp
> b) destroys all servlets
> c) serializes all the Sessions
> d) throws away the ClassLoader for this webapp
> e) cleans away the webapp from all "caches" in the system
> f) restarts the whole webapp, as if for the first time, making a new
>     ClassLoader for it.
> g) deserializes all the Sessions (now with the new ClassLoader)
> h) lets the users use the system again
>
> (Which is apparently how tomcat 4 should do it, but it never did for me.
> But I am doing a very weird ting according to the developers, I am running
> tomcat away from it's installation directory, and this is _not_
> supported.)
>
> What tomcat3x does, is to just ditches the ClassLoader and reloads the
> _first_ servlet you hit after a refresh of the .class-files timestamps.
> Even if you recompile your whole webapp, tomcat just reloads the first
> servlet a user hits. This means that all the other Servlets are still
> "cached" using the old ClassLoader, and you actually get two instanses of
> your webapp, all the old Session objects and all the other Servlets loaded
> with the old ClassLoader, while all the new Session objects and the one,
> first hit Servlet with the new ClassLoader.
>   It doesn't, as mentioned, do anything about the Session variables, and
> therefore you often get ClassCastExceptions when you try to handle and
> cast objects gotten from the Session within the one, new reloaded servlet.
> This because _it's_ version of the Class you try to cast the object gotten
> from the Session to, is loaded with the new ClassLoader, while the object
> you try to cast is loaded with the old. This is not considered the same
> Classes, and you get ClassCastException.
>
> This is so very, very wrong, and therefore I'd say it's "totally fucked"..
> This has been pointed out a whole bunch of times.
>
> Better? I'm not that fantastic with English, hope you excuse that, Joel.
>
> Endre.