On Mon, 26 Nov 2001, Mika Goeckel wrote:
> Date: Mon, 26 Nov 2001 15:05:27 +0100
> From: Mika Goeckel <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
>
> Hi,
>
> could you get around the singleton problem by placing the singleton object's
> class outside the classloader which get busted when reloading the changed
> servlets/jsps? You could move it up to the 'shared' or even 'common'
> classspace. Do I understand it right, that these class loaders are not being
> destroyed when TC is running? I'm not so deep into that matter, maybe I
> completely misunderstand something...
>
You are correct that any classes loaded by the "common" or "shared" classs
loaders are not replaced when an application reload occurs. A consequence
of this statement is that you must restart Tomcat if any such shared class
is updated and you want Tomcat to use the new version.
Servlet 2.3 provides the appropriate hooks (context started and stopped
events) to deal with this issue. Details are left to the application.
> Mika
>
Craig
> ----- Original Message -----
> From: "Kevin A. Burton" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, November 26, 2001 8:52 AM
> Subject: Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jon Stevens <[EMAIL PROTECTED]> writes:
> >
> > > on 11/25/01 9:57 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Of course, there's a reason for this, as a selective reloading would
> be a
> > > > very complex thing to do.
> > > >
> > > > Remy
> > >
> > > More like damn near impossible. Once the previous classloader has been
> > > trashed, all objects which were created within it would then become
> invalid.
> > >
> > > Kevin, the right thing to do is to setup something like Turbine's
> Services
> > > which have a shutdown process which can be invoked when the servlets
> destroy()
> > > method is called in order to shutdown the singletons.
> >
> > Ah. Interesting. This technique would work but would require the
> 'restart'
> > (there's that word again) the whole application.
> >
> > ... at this point I think it might make sense just to restart Tomcat as
> shutting
> > down and restarting the app would take just as long as a full restart.
> >
> > It is a shame because there is a lot of potential in just reloading that
> one
> > class.
> >
> > > Sadly, I have to admit that the Turbine Services framework shutdown code
> is
> > > currently broken and has been for some time now...it needs to be
> re-written...
> >
> > Are you saying that the theory is broken or just Turbine's impl?
> >
> > Kevin
> >
> > - --
> > Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED] )
> > Location - San Francisco, CA, Cell - 415.595.9965
> > Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/
> >
> > Windows 95 - A 32 bit extension to a 16 bit shell for a 8 bit operating
> system
> > designed for 4 bit computers by a 2 bit company that can't stand 1 bit of
> > competition.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
> >
> > iD8DBQE8AfRrAwM6xb2dfE0RAuB1AJ0aAkQbAp5lkmnUMOVJ0BG0Ipf6YwCghsRo
> > +avbgG+W5aqsXELI1RKaPcI=
> > =Aq5S
> > -----END PGP SIGNATURE-----
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
