<<
before I go any further, I'm assuming that if I'm saying something that
isn't right someone
>>
Not to worry - we are all techies...
<<
> 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.
>>
You are correct. What I meant is that to dynamically unload Class
definition
(that is nullifying it by traversing the method area) one must write a
special
program - probably in assembler at that
<<
> 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...
>>
You are correct again, although somebody posted that this does't work
well either - something wrong with static methods or fields - don't remember
for sure
----- 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?
