One more thing:
<<
The reasoning behind this is to prevent some malicious program from
replacing
a class definition with their own
>>
This is generally correct. Although - there is a way to tell (if one is bold
enough
to extend ClassLoader properties) which ClassLoader this or that
ClassDefinition came from. There must be, because there is only one Method
Area for JVM.
So in order to keep separate namespaces for the classes that came from
different
ClassLoader method area keeps references to all ClassLoaders and their
associated classes.
Just thought you might want to know.
R/Luba
----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 17, 2001 9:02 AM
Subject: Re: session error after recompile a java class....BUG?
> before I go any further, I'm assuming that if I'm saying something that
> isn't right someone who knows so will correct it so that I dont mislead
> ppl, but this is my understanding of things...
>
> ant is available at http://jakarta.apache.org/ant and is a "make" style
> product that is very nice for developing java projects... I'm sure
> you'll find the site helpful.
>
> I thought, and I want someone to correct me here if I'm wrong, that
> Classloaders dont unload class definitions. The reasoning behind this
> is to prevent some malicious program from replacing a class definition
> with their own. I'm assuming that tomcat creates a new classloader for
> each context, and through some tweaking there is able to provide the
> reload facility, although I haven't looked at _any_ of the tomcat code
> so am not sure what happens under the covers. this is a little off
> point though...
>
> > My understanding is that dynamically loaded Class definition are subject
to
> > gc just like
> > regular objects. For this to happen Class definition has to be
nullified.
> > For this to happen
> > the system must have the capacity to locate the Class data in the method
> > area, locate Class
> > instances for the object's class, it's supers and interfaces. In most
> > implementations garbage
> > collected data is literally moved to another area on the heap.
> > Too much work when one can just restart Tomcat server...
> I dont think the question is whether a class is reloaded or not, as
> tomcat provides that facility for us. I think the question is can we
> have an in memory representation of an object be accessed using two
> different class definitions. It makes sense to me that you cant. I'm
> not a C programmer, so excuse my lack of low-level experience, but if
> the objects internal representation changes between compiles (which I'm
> guessing the "serial number" of a class changing would effectily do),
> then you wouldn't be able to take part of the heap and represent it as
> an object, when it doesn't fit the expected representation. right or
> wrong? I dont know.. just thinking aloud, or rather, via email (o:
>
> am I making sense?
>
> cheers
> dim
>
>
> >
> > >>
> > You can get around this by using something like ant that
> > only recompiles changed files
> > <<
> >
> > Can you point me to the direction where I can read more about ANT. Is
it
> > difficult to
> > configure?
> >
> > Thanks,
> > luba
> >
> > ----- Original Message -----
> > From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, June 17, 2001 6:12 AM
> > Subject: Re: session error after recompile a java class....BUG?
> >
> > > Everything works fine as long as you dont reload a class right? I
would
> > > suggest that what you have is perfectly understandable. You create an
> > > object and put it in the session, based on one set of bytecode. You
> > > then replace the bytecode with new bytecode, and the JVM is trying to
> > > access the object as type of the second set of bytecode. That's where
> > > your problem is occuring. I dont think this is a Tomcat bug, just a
> > > limitation on how much dynamic classloading can do - you cant expect
it
> > > to automatically migrate old objects to new versions of the same type.
> > >
> > > I'm guessing what might be happening is you make a small change to
> > > something not related to this object, and then recompile. Its
> > > understandable that you dont expect any changes to the object we're
> > > talking about, but because you've recompiled all the classes, we have
> > > this problem. You can get around this by using something like ant
that
> > > only recompiles changed files. That way you only reload the classes
you
> > > need to.
> > >
> > > hope this helps
> > > cheers
> > > dim
> > >
> > > istvan bereti wrote:
> > > >
> > > > If I get the bound object from the session right after I put it in
it's
> > > > correct. But after the first request with the same session I got the
> > > > ClassCastError.
> > > > Has anyone experienced the same?
> > > > The same code worked perfectly with JServ.
> > > >
> > > > Hi,
> > > >
> > > > I don't know what is wrong but it might be a Tomcat bug...
> > > > My session handling is working fine as long as I don't reload a
class.
> > Than
> > > > the object bound to the session is very ugly. I got the object from
the
> > > > session and the getClass() says that it's my BoundObject class. But
whe
> > I
> > > > try to cast it to (BoundObject) says ClassCastError.
> > > >
> > > > Any idea why?
