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?
