reloading..

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

I'm going a bit crazy soon, so any help here would be much appreciated!

I have a DB pool. I instantiate this class as a "connection holder", and
the pool is a static field in this class. I also have a static int that I
increase each time I make a new of these connection holders, and decrease
each time they get garbage collected.
  I Initialize this from a servlet (Startup.java) that I've defined as
"load-on-startup". This goes just fine, and everything is merry.

When I recompile my servlets, beans and helpers (rm all .class files, and
jikes the whole thing), I apparently have "lost" this pool somewhere. I
get a nullpointer exception at the point where I try to reference it. The
counter I was talking about has also been reset to zero.

I then tried to put a call to the initialization in the "doGet()" of the
Startup.java, so that I can call it when I need it. This is when things
get annyoing.
  I now (sometimes!) apparently get two different "contexts" of servlets.
This because the call to Startup.java and this other servlet gives me
_different_ values from this counter. So the Startup.java is happy,
because the pool is working fine there, but my main servlet hasn't got the
same class or whatever.

As I've understood it, this is because I now have two different
classloaders loading these classes, and in reality, two enirely different
contexts. Is this really the way it's meant to be, or am I totally doing
something wrong?

Is there _anything_ I can do from within the servlets to just get rid of
ALL classes and start all over if tomcat notices a "reload-situation"? If
I have to go to the tomcat source, where should I start?!

Any help would much appreciated.

-- 
Mvh,
Endre

Re: reloading..

[Dave Smith <sa...@home.com>]

Endre,

Java was not designed as a language in which classes can be changed on the
fly.
There are basic security issues at stake. The reload feature is just a hack
anyway,
albiet a clever one. It is useful for beginners but unnecessary once you
have
more experience with the codebase.

Regards,

DRS

----- Original Message -----
From: "Endre Stølsvik" <En...@Stolsvik.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, November 28, 2000 11:23 AM
Subject: Re: reloading..


> On Tue, 28 Nov 2000, David Molloy wrote:
>
> | I was very happy when I got this all working but as it happens I still
> | need to restart Tomcat after I make changes.  You'll find if you use
> | sessions to store classes (in my case I store the User class in a
> | session variable called theUser) there seems to be a problem with
> | reloading.  If anyone has anything to add to this I'd be grateful
> | but I'd asked it before.  Seemingly when you cause a class reload
> | the classes reload but the sessions don't invalidate - so when you
> | do a req.getSession(true) you'll find that it grabs the old one and
> | when you try to grab theUser it will give a ClassCastException.
> | As another person commented before - it seems like a feature but
> | it's more like a bug.
>
> Thanks! Seems like we have exactly the same problems, I also have this
> UserSession object in the session, and get ClassCast all the time.
>
> Isn't this such a needed feature for developing in Tomcat that it should
> be included as a option for a webapp? "reloadable=true" and
> "on-reload;invalidate-the-session,ditch-all-the-classes,basically-do-a-
> complete-restart,but-somewhat-transparently-for-the-developer=true"
>
> It wouldn't be a problem to reinitialize the UserSession if it came back
> from the Session as "null". Especially if it was invalidated before it got
> shut down, because I could then store the state. And then Tomcat started
> to load all classes "on demand" again. Maybe it even had to run through
> the "load-on-startup" servlets.. But it would be the new, fresh classes,
> not any stale, loaded-with-the-old-classloader stuff.
>
>
> --
> Mvh,
> Endre
>
>

Re: reloading..

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

On Tue, 28 Nov 2000, David Molloy wrote:

| I was very happy when I got this all working but as it happens I still
| need to restart Tomcat after I make changes.  You'll find if you use
| sessions to store classes (in my case I store the User class in a
| session variable called theUser) there seems to be a problem with
| reloading.  If anyone has anything to add to this I'd be grateful
| but I'd asked it before.  Seemingly when you cause a class reload
| the classes reload but the sessions don't invalidate - so when you
| do a req.getSession(true) you'll find that it grabs the old one and
| when you try to grab theUser it will give a ClassCastException.
| As another person commented before - it seems like a feature but
| it's more like a bug.

Thanks! Seems like we have exactly the same problems, I also have this
UserSession object in the session, and get ClassCast all the time.

Isn't this such a needed feature for developing in Tomcat that it should
be included as a option for a webapp? "reloadable=true" and
"on-reload;invalidate-the-session,ditch-all-the-classes,basically-do-a-
complete-restart,but-somewhat-transparently-for-the-developer=true"

It wouldn't be a problem to reinitialize the UserSession if it came back
from the Session as "null". Especially if it was invalidated before it got
shut down, because I could then store the state. And then Tomcat started
to load all classes "on demand" again. Maybe it even had to run through
the "load-on-startup" servlets.. But it would be the new, fresh classes,
not any stale, loaded-with-the-old-classloader stuff.


-- 
Mvh,
Endre

RE: reloading..

[David Molloy <mo...@eeng.dcu.ie>]

Hi,

	I have something similar in place but it's working pretty much.
Set up one web application area with all your database classes,
ConnectionPool etc.  Make this area non-class reloadable and put
a load-on-startup on the pool.  Now assuming you make static references
to the ConnectionPool then you can reference it from other web
applications.  All the while you can develop in these applications
with class reloading enabled (as you are not directly affecting
your connection pool anymore) and it should work....

I was very happy when I got this all working but as it happens I still
need to restart Tomcat after I make changes.  You'll find if you use
sessions to store classes (in my case I store the User class in a
session variable called theUser) there seems to be a problem with
reloading.  If anyone has anything to add to this I'd be grateful
but I'd asked it before.  Seemingly when you cause a class reload
the classes reload but the sessions don't invalidate - so when you
do a req.getSession(true) you'll find that it grabs the old one and
when you try to grab theUser it will give a ClassCastException.
As another person commented before - it seems like a feature but
it's more like a bug.

Dave



-----Original Message-----
From: Alistair Hopkins [mailto:alistair@berthengron.co.uk]
Sent: Monday, November 27, 2000 4:58 PM
To: tomcat-user@jakarta.apache.org
Subject: RE: reloading..


give up, restart tomcat.

i found that to be the only sureproof way :-(

-----Original Message-----
From: Endre Stølsvik [mailto:Endre@Stolsvik.com]
Sent: Monday, November 27, 2000 4:49 PM
To: tomcat-user@jakarta.apache.org
Subject: reloading..


I'm going a bit crazy soon, so any help here would be much appreciated!

I have a DB pool. I instantiate this class as a "connection holder", and
the pool is a static field in this class. I also have a static int that I
increase each time I make a new of these connection holders, and decrease
each time they get garbage collected.
  I Initialize this from a servlet (Startup.java) that I've defined as
"load-on-startup". This goes just fine, and everything is merry.

When I recompile my servlets, beans and helpers (rm all .class files, and
jikes the whole thing), I apparently have "lost" this pool somewhere. I
get a nullpointer exception at the point where I try to reference it. The
counter I was talking about has also been reset to zero.

I then tried to put a call to the initialization in the "doGet()" of the
Startup.java, so that I can call it when I need it. This is when things
get annyoing.
  I now (sometimes!) apparently get two different "contexts" of servlets.
This because the call to Startup.java and this other servlet gives me
_different_ values from this counter. So the Startup.java is happy,
because the pool is working fine there, but my main servlet hasn't got the
same class or whatever.

As I've understood it, this is because I now have two different
classloaders loading these classes, and in reality, two enirely different
contexts. Is this really the way it's meant to be, or am I totally doing
something wrong?

Is there _anything_ I can do from within the servlets to just get rid of
ALL classes and start all over if tomcat notices a "reload-situation"? If
I have to go to the tomcat source, where should I start?!

Any help would much appreciated.

--
Mvh,
Endre

Re: reloading..

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

On Mon, 27 Nov 2000, Alistair Hopkins wrote:

| give up, restart tomcat.
| 
| i found that to be the only sureproof way :-(

Hmm.. This isn't exactly the solution I wanted!

Isn't there any other way, or anyone that can give me any clues of where
to _start_ looking for a solution?!

Thanks!

-- 
Mvh,
Endre

RE: reloading..

[Alistair Hopkins <al...@berthengron.co.uk>]

give up, restart tomcat.

i found that to be the only sureproof way :-(

-----Original Message-----
From: Endre Stølsvik [mailto:Endre@Stolsvik.com]
Sent: Monday, November 27, 2000 4:49 PM
To: tomcat-user@jakarta.apache.org
Subject: reloading..


I'm going a bit crazy soon, so any help here would be much appreciated!

I have a DB pool. I instantiate this class as a "connection holder", and
the pool is a static field in this class. I also have a static int that I
increase each time I make a new of these connection holders, and decrease
each time they get garbage collected.
  I Initialize this from a servlet (Startup.java) that I've defined as
"load-on-startup". This goes just fine, and everything is merry.

When I recompile my servlets, beans and helpers (rm all .class files, and
jikes the whole thing), I apparently have "lost" this pool somewhere. I
get a nullpointer exception at the point where I try to reference it. The
counter I was talking about has also been reset to zero.

I then tried to put a call to the initialization in the "doGet()" of the
Startup.java, so that I can call it when I need it. This is when things
get annyoing.
  I now (sometimes!) apparently get two different "contexts" of servlets.
This because the call to Startup.java and this other servlet gives me
_different_ values from this counter. So the Startup.java is happy,
because the pool is working fine there, but my main servlet hasn't got the
same class or whatever.

As I've understood it, this is because I now have two different
classloaders loading these classes, and in reality, two enirely different
contexts. Is this really the way it's meant to be, or am I totally doing
something wrong?

Is there _anything_ I can do from within the servlets to just get rid of
ALL classes and start all over if tomcat notices a "reload-situation"? If
I have to go to the tomcat source, where should I start?!

Any help would much appreciated.

--
Mvh,
Endre