You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dmitri Colebatch <di...@ozemail.com.au> on 2001/06/17 12:12:49 UTC

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?

Re: session error after recompile a java class....BUG?

Posted by Luba Powell <lu...@bellatlantic.net>.
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" <di...@ozemail.com.au>
To: <to...@jakarta.apache.org>
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" <di...@ozemail.com.au>
> > To: <to...@jakarta.apache.org>
> > 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?


Re: session error after recompile a java class....BUG?

Posted by Luba Powell <lu...@bellatlantic.net>.
<<
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" <di...@ozemail.com.au>
To: <to...@jakarta.apache.org>
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" <di...@ozemail.com.au>
> > To: <to...@jakarta.apache.org>
> > 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?


Re: session error after recompile a java class....BUG?

Posted by Dmitri Colebatch <di...@ozemail.com.au>.
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" <di...@ozemail.com.au>
> To: <to...@jakarta.apache.org>
> 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?

Re: session error after recompile a java class....BUG?

Posted by Luba Powell <lu...@bellatlantic.net>.
Hello Dmitri--
<<
 - you cant expect it to automatically migrate old objects to new versions
of the same type.
>>

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...

>>
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" <di...@ozemail.com.au>
To: <to...@jakarta.apache.org>
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?


Re: session error after recompile a java class....BUG?

Posted by Luba Powell <lu...@bellatlantic.net>.
Hello, Itsvan--
I think there is a bug in their Class loaders, or the strategy has not been
thought out thru.  There have been numerous postings on this subject.
But I guess nothing will happen unless the community start to document
and report those bugs instead of working around them, of which I am
the first culprit.

----- Original Message -----
From: "istvan bereti" <is...@kolumbus.fi>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 12:00 AM
Subject: RE: session error after recompile a java class....BUG?


> Well I just noticed that there is also a reloading problem... generally it
> is not reloading my classes. My WEB_INF/classes are not in the classpath
and
> in the server.xml I specified to reload it. I don't have any JAR that
might
> contain the same classes.
> Well I think I will restart TOMCAT instead of waiting to reload my
> classes...
>
>
> Istvan,
>
> hmmm... ok, I dont really know anything about JServ, so cant really
> comment on the way JServ allows you to reload classes (does it do
> that?), but I dont think its the code thats broken, it sounds more like
> some classpath issue.  I'm not sure I'm going to have an answer, but
> something else that might be happening is if the class is in your
> classpath when you start tomcat then it wont be able to reload it (I'm
> still not clear on why it needs to if you're doing something that
> doesn't affect the class), so check when  you start tomcat what
> classpath it gives you.  Wherever you compile the classes to should not
> be in that classpath.  Is that it?
>
> Failing that, I think someone with more intimate knowledge of tomcat
> might be required for your problem.  Could you give a definate example
> (ie, AServlet, uses AnObject and puts it in the session, I recompile
> AHelper, that is not used by AServlet or AnObject, and I get a
> ClassCastException in AServlet.doGet).
>
> cheers
> dim
>
> istvan bereti wrote:
> >
> > HI Dim,
> >
> > Well thanks to think about my problem. I understand your answer but you
> > think if I recompile only one class this session binding error should
not
> > happen. Well I compiled only one class which is absolutely not related
to
> > the session but the problem still occures.
> > So I compiled a helper class which is not related at all with the
session.
> > What I got is the session getAttribute() gets the bound object and it's
> the
> > right class.
> > But when I cast I get a ClassCastError as I said.
> >
> > I checked if it's really in the session so right after bounding the
object
> I
> > also fetch it. It also works. But after the first request from the
client
> > browser, it can't cast the object bound to the session.
> >
> > As I said it worked perfectly with Jserv.
> >
> > If I restart TOMCAT it works again fine as long as I don't recompile any
> > class....
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: dim@coxless.com [mailto:dim@coxless.com]On Behalf Of Dmitri
> > Colebatch
> > Sent: Sunday, June 17, 2001 3:13 AM
> > To: tomcat-user@jakarta.apache.org
> > 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?
>
>


RE: session error after recompile a java class....BUG?

Posted by istvan bereti <is...@kolumbus.fi>.
Well I just noticed that there is also a reloading problem... generally it
is not reloading my classes. My WEB_INF/classes are not in the classpath and
in the server.xml I specified to reload it. I don't have any JAR that might
contain the same classes.
Well I think I will restart TOMCAT instead of waiting to reload my
classes...


Istvan,

hmmm... ok, I dont really know anything about JServ, so cant really
comment on the way JServ allows you to reload classes (does it do
that?), but I dont think its the code thats broken, it sounds more like
some classpath issue.  I'm not sure I'm going to have an answer, but
something else that might be happening is if the class is in your
classpath when you start tomcat then it wont be able to reload it (I'm
still not clear on why it needs to if you're doing something that
doesn't affect the class), so check when  you start tomcat what
classpath it gives you.  Wherever you compile the classes to should not
be in that classpath.  Is that it?

Failing that, I think someone with more intimate knowledge of tomcat
might be required for your problem.  Could you give a definate example
(ie, AServlet, uses AnObject and puts it in the session, I recompile
AHelper, that is not used by AServlet or AnObject, and I get a
ClassCastException in AServlet.doGet).

cheers
dim

istvan bereti wrote:
>
> HI Dim,
>
> Well thanks to think about my problem. I understand your answer but you
> think if I recompile only one class this session binding error should not
> happen. Well I compiled only one class which is absolutely not related to
> the session but the problem still occures.
> So I compiled a helper class which is not related at all with the session.
> What I got is the session getAttribute() gets the bound object and it's
the
> right class.
> But when I cast I get a ClassCastError as I said.
>
> I checked if it's really in the session so right after bounding the object
I
> also fetch it. It also works. But after the first request from the client
> browser, it can't cast the object bound to the session.
>
> As I said it worked perfectly with Jserv.
>
> If I restart TOMCAT it works again fine as long as I don't recompile any
> class....
>
> Any ideas?
>
> -----Original Message-----
> From: dim@coxless.com [mailto:dim@coxless.com]On Behalf Of Dmitri
> Colebatch
> Sent: Sunday, June 17, 2001 3:13 AM
> To: tomcat-user@jakarta.apache.org
> 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?



Re: session error after recompile a java class....BUG?

Posted by Dmitri Colebatch <di...@ozemail.com.au>.
Istvan,

hmmm... ok, I dont really know anything about JServ, so cant really
comment on the way JServ allows you to reload classes (does it do
that?), but I dont think its the code thats broken, it sounds more like
some classpath issue.  I'm not sure I'm going to have an answer, but
something else that might be happening is if the class is in your
classpath when you start tomcat then it wont be able to reload it (I'm
still not clear on why it needs to if you're doing something that
doesn't affect the class), so check when  you start tomcat what
classpath it gives you.  Wherever you compile the classes to should not
be in that classpath.  Is that it?  

Failing that, I think someone with more intimate knowledge of tomcat
might be required for your problem.  Could you give a definate example
(ie, AServlet, uses AnObject and puts it in the session, I recompile
AHelper, that is not used by AServlet or AnObject, and I get a
ClassCastException in AServlet.doGet).

cheers
dim

istvan bereti wrote:
> 
> HI Dim,
> 
> Well thanks to think about my problem. I understand your answer but you
> think if I recompile only one class this session binding error should not
> happen. Well I compiled only one class which is absolutely not related to
> the session but the problem still occures.
> So I compiled a helper class which is not related at all with the session.
> What I got is the session getAttribute() gets the bound object and it's the
> right class.
> But when I cast I get a ClassCastError as I said.
> 
> I checked if it's really in the session so right after bounding the object I
> also fetch it. It also works. But after the first request from the client
> browser, it can't cast the object bound to the session.
> 
> As I said it worked perfectly with Jserv.
> 
> If I restart TOMCAT it works again fine as long as I don't recompile any
> class....
> 
> Any ideas?
> 
> -----Original Message-----
> From: dim@coxless.com [mailto:dim@coxless.com]On Behalf Of Dmitri
> Colebatch
> Sent: Sunday, June 17, 2001 3:13 AM
> To: tomcat-user@jakarta.apache.org
> 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?

Re: What are EJB

Posted by Luba Powell <lu...@bellatlantic.net>.
putting Tomcat in your message was smart.  this way we won't get in
trouble with our colleagues.

>From were I stand the only thing that EJB and JavaBeans have in
common is the presence of bean work in the name.

I am sure that you know what is the advantage of JavaBeans since
you wrote some.  EJB is normally used in e-commerce applications
that remotely communicate with enterprise databases and maintain
sessions across many machines.  Again, from where I stand - they
are perfect for some e-commerce apps, but it is not the greatest fit
of engineering.

There is a way to include EJBs in Tomcat4.  Haven't tried it yet.

r/luba


----- Original Message -----
From: "Alexandre Bouchard" <ro...@mac.com>
To: <to...@jakarta.apache.org>
Sent: Sunday, June 17, 2001 1:07 PM
Subject: What are EJB


> I've got a simple question: What are Enterprise Java Beans. I mean, what's
> the difference between EJB and the beans I develop with JDK and run with
> Tomcat?
>
> Thx
>
>


Re: What are EJB

Posted by Luba Powell <lu...@bellatlantic.net>.
thank you - no rush.  can wait until next week.
r/luba
----- Original Message -----
From: "Sam Newman" <sa...@stamplets.com>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 4:54 PM
Subject: Re: What are EJB


> Hmm...I can certainly send you the config files Orcas uses to work with
> Tomcat. I'll try and dig them out (off site at the moment - back next
week).
> One way to communicate with an EJB container without any config problems
at
> all, is to use RMI.You bind an RMI object at your EJB container's machine,
> which will act as a proxy to the EJB (mine is in fact called
> CentralServerProxy). Your servlets then act as an RMI client. All you have
> to do to get this to work is run tomcat with a security manager (so you'll
> need java 2, and you have to uncomment the relevent line out of your
> server.xml), start an RMI security manager before retrieving the reference
> to the object, and tailor your tomcat.policy file to allow access (I ended
> up granting everything full permissions because I couldn't be bothered to
do
> it properly :-) ). The beauty of this approach is that:
> 1.)Tomcat doesn't have to be on the same machine as your EJB container as
> the communication is RMI (wouldn't be that secure though). It could even
> work over the web (RMI is simply a Java specific layer on Corba).
> 2.) You abstract the underlying EJB container. Different containers might
> require different configuration's for tomcat and the container itself to
get
> communication to work.
> I can go into more detail if you want (I have the code here). It doesn't
> take too long to setup, and you can easily protoype the system without an
> EJB container behind your Proxy RMI object - you could equally just use
JDBC
> to connect to MySql or something. Using servlets as an RMI client is
> outlines in the Servlet Programming book, in the odds and ends chapter I
> think (left my copy at the office!).
> Obviously you could use other communication mechanisms to abstract the
> communication - we also use 1024 bit encrypted secure pipes to communicate
> over the web between out central EJB server and client processes.
>
> sam
> ----- Original Message -----
> From: "Luba Powell" <lu...@bellatlantic.net>
> To: <to...@jakarta.apache.org>
> Sent: Monday, June 18, 2001 5:31 PM
> Subject: Re: What are EJB
>
>
> > You think so?  I will give in another chance.
> > Can you send to me configurations for Tomcat/EJB?
> >
> > thank you.
>
>


Re: What are EJB

Posted by Sam Newman <sa...@stamplets.com>.
Hmm...I can certainly send you the config files Orcas uses to work with
Tomcat. I'll try and dig them out (off site at the moment - back next week).
One way to communicate with an EJB container without any config problems at
all, is to use RMI.You bind an RMI object at your EJB container's machine,
which will act as a proxy to the EJB (mine is in fact called
CentralServerProxy). Your servlets then act as an RMI client. All you have
to do to get this to work is run tomcat with a security manager (so you'll
need java 2, and you have to uncomment the relevent line out of your
server.xml), start an RMI security manager before retrieving the reference
to the object, and tailor your tomcat.policy file to allow access (I ended
up granting everything full permissions because I couldn't be bothered to do
it properly :-) ). The beauty of this approach is that:
1.)Tomcat doesn't have to be on the same machine as your EJB container as
the communication is RMI (wouldn't be that secure though). It could even
work over the web (RMI is simply a Java specific layer on Corba).
2.) You abstract the underlying EJB container. Different containers might
require different configuration's for tomcat and the container itself to get
communication to work.
I can go into more detail if you want (I have the code here). It doesn't
take too long to setup, and you can easily protoype the system without an
EJB container behind your Proxy RMI object - you could equally just use JDBC
to connect to MySql or something. Using servlets as an RMI client is
outlines in the Servlet Programming book, in the odds and ends chapter I
think (left my copy at the office!).
Obviously you could use other communication mechanisms to abstract the
communication - we also use 1024 bit encrypted secure pipes to communicate
over the web between out central EJB server and client processes.

sam
----- Original Message -----
From: "Luba Powell" <lu...@bellatlantic.net>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 5:31 PM
Subject: Re: What are EJB


> You think so?  I will give in another chance.
> Can you send to me configurations for Tomcat/EJB?
>
> thank you.



Re: What are EJB

Posted by Luba Powell <lu...@bellatlantic.net>.
You think so?  I will give in another chance.
Can you send to me configurations for Tomcat/EJB?

thank you.
----- Original Message -----
From: "Sam Newman" <sa...@stamplets.com>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 12:14 PM
Subject: Re: What are EJB


> Problem is all the containers we've used up till now have had real
problems
> with bean managed persistance...as a result we had to avoid it. They seem
> better now, but its a bit late for us. The single biggest headache I've
had
> developing/designing EJB's is trying to make the OO centric java (e.g.
> encapsulation of data and process) work with the non-OO databases without
> sacrificing too many of the advantages of the two (databases speed, Javas
> flexibility).
> I'm looking forward to the new message beans which are in the new EJB 2.0
> spec. Would of made my current project a whole lot easier... Sending
> messages/setting state of beans via JMS could be very cool - if it works
:-)
>
> sam
>
> ----- Original Message -----
> From: "Luba Powell" <lu...@bellatlantic.net>
> To: <to...@jakarta.apache.org>
> Sent: Monday, June 18, 2001 4:38 PM
> Subject: Re: What are EJB
>
>
> > << but a real mess of a database....>>
> >
> > You are right here.  Because of it I stopped using Entity beans all
> > together...
> >
> >
> > ----- Original Message -----
> > From: "Sam Newman" <sa...@stamplets.com>
> > To: <to...@jakarta.apache.org>
> > Sent: Monday, June 18, 2001 9:26 AM
> > Subject: Re: What are EJB
> >
> >
> > > The only real similarity between EJB's and normal JavaBeans is that
they
> > are
> > > both based on component models. EJB's provide a java representation of
> > some
> > > data in a database - e.g. 1 EJB will equal 1 row in the table, 1 EJB
> class
> > > is tied to one table. XML is used to tie an EJB and its data to a
> > database.
> > > There is a bit of a problem with this approach, in that a typical OO
> > design
> > > for such a system can result in a good OO system on the surface, but a
> > real
> > > mess of a database....
> > >
> > > EJB's need a compliant EJB server, and a database. There are a few
free
> > > versions around - try JBoss. They work fine with Servlets/Tomcat given
> > that
> > > they are also part of the j2ee. I personally use Cape Connect
(previosly
> > > Orcas) with tomcat without too many problems (there are a couple of
> class
> > > loader issues in some circumstances however). Orcas actually bundles
> > Tomcat
> > > with it, and they pre-configure it to work with their ejb container.
> > >
> > > sam
> > > ----- Original Message -----
> > > From: "Alexandre Bouchard" <ro...@mac.com>
> > > To: <to...@jakarta.apache.org>
> > > Sent: Sunday, June 17, 2001 6:07 PM
> > > Subject: What are EJB
> > >
> > >
> > > > I've got a simple question: What are Enterprise Java Beans. I mean,
> > what's
> > > > the difference between EJB and the beans I develop with JDK and run
> with
> > > > Tomcat?
> > > >
> > > > Thx
> > > >
> > >
> >
>


Re: What are EJB

Posted by Sam Newman <sa...@stamplets.com>.
Problem is all the containers we've used up till now have had real problems
with bean managed persistance...as a result we had to avoid it. They seem
better now, but its a bit late for us. The single biggest headache I've had
developing/designing EJB's is trying to make the OO centric java (e.g.
encapsulation of data and process) work with the non-OO databases without
sacrificing too many of the advantages of the two (databases speed, Javas
flexibility).
I'm looking forward to the new message beans which are in the new EJB 2.0
spec. Would of made my current project a whole lot easier... Sending
messages/setting state of beans via JMS could be very cool - if it works :-)

sam

----- Original Message -----
From: "Luba Powell" <lu...@bellatlantic.net>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 4:38 PM
Subject: Re: What are EJB


> << but a real mess of a database....>>
>
> You are right here.  Because of it I stopped using Entity beans all
> together...
>
>
> ----- Original Message -----
> From: "Sam Newman" <sa...@stamplets.com>
> To: <to...@jakarta.apache.org>
> Sent: Monday, June 18, 2001 9:26 AM
> Subject: Re: What are EJB
>
>
> > The only real similarity between EJB's and normal JavaBeans is that they
> are
> > both based on component models. EJB's provide a java representation of
> some
> > data in a database - e.g. 1 EJB will equal 1 row in the table, 1 EJB
class
> > is tied to one table. XML is used to tie an EJB and its data to a
> database.
> > There is a bit of a problem with this approach, in that a typical OO
> design
> > for such a system can result in a good OO system on the surface, but a
> real
> > mess of a database....
> >
> > EJB's need a compliant EJB server, and a database. There are a few free
> > versions around - try JBoss. They work fine with Servlets/Tomcat given
> that
> > they are also part of the j2ee. I personally use Cape Connect (previosly
> > Orcas) with tomcat without too many problems (there are a couple of
class
> > loader issues in some circumstances however). Orcas actually bundles
> Tomcat
> > with it, and they pre-configure it to work with their ejb container.
> >
> > sam
> > ----- Original Message -----
> > From: "Alexandre Bouchard" <ro...@mac.com>
> > To: <to...@jakarta.apache.org>
> > Sent: Sunday, June 17, 2001 6:07 PM
> > Subject: What are EJB
> >
> >
> > > I've got a simple question: What are Enterprise Java Beans. I mean,
> what's
> > > the difference between EJB and the beans I develop with JDK and run
with
> > > Tomcat?
> > >
> > > Thx
> > >
> >
>


Re: What are EJB

Posted by Luba Powell <lu...@bellatlantic.net>.
<< but a real mess of a database....>>

You are right here.  Because of it I stopped using Entity beans all
together...


----- Original Message -----
From: "Sam Newman" <sa...@stamplets.com>
To: <to...@jakarta.apache.org>
Sent: Monday, June 18, 2001 9:26 AM
Subject: Re: What are EJB


> The only real similarity between EJB's and normal JavaBeans is that they
are
> both based on component models. EJB's provide a java representation of
some
> data in a database - e.g. 1 EJB will equal 1 row in the table, 1 EJB class
> is tied to one table. XML is used to tie an EJB and its data to a
database.
> There is a bit of a problem with this approach, in that a typical OO
design
> for such a system can result in a good OO system on the surface, but a
real
> mess of a database....
>
> EJB's need a compliant EJB server, and a database. There are a few free
> versions around - try JBoss. They work fine with Servlets/Tomcat given
that
> they are also part of the j2ee. I personally use Cape Connect (previosly
> Orcas) with tomcat without too many problems (there are a couple of class
> loader issues in some circumstances however). Orcas actually bundles
Tomcat
> with it, and they pre-configure it to work with their ejb container.
>
> sam
> ----- Original Message -----
> From: "Alexandre Bouchard" <ro...@mac.com>
> To: <to...@jakarta.apache.org>
> Sent: Sunday, June 17, 2001 6:07 PM
> Subject: What are EJB
>
>
> > I've got a simple question: What are Enterprise Java Beans. I mean,
what's
> > the difference between EJB and the beans I develop with JDK and run with
> > Tomcat?
> >
> > Thx
> >
>


Re: What are EJB

Posted by Sam Newman <sa...@stamplets.com>.
The only real similarity between EJB's and normal JavaBeans is that they are
both based on component models. EJB's provide a java representation of some
data in a database - e.g. 1 EJB will equal 1 row in the table, 1 EJB class
is tied to one table. XML is used to tie an EJB and its data to a database.
There is a bit of a problem with this approach, in that a typical OO  design
for such a system can result in a good OO system on the surface, but a real
mess of a database....

EJB's need a compliant EJB server, and a database. There are a few free
versions around - try JBoss. They work fine with Servlets/Tomcat given that
they are also part of the j2ee. I personally use Cape Connect (previosly
Orcas) with tomcat without too many problems (there are a couple of class
loader issues in some circumstances however). Orcas actually bundles Tomcat
with it, and they pre-configure it to work with their ejb container.

sam
----- Original Message -----
From: "Alexandre Bouchard" <ro...@mac.com>
To: <to...@jakarta.apache.org>
Sent: Sunday, June 17, 2001 6:07 PM
Subject: What are EJB


> I've got a simple question: What are Enterprise Java Beans. I mean, what's
> the difference between EJB and the beans I develop with JDK and run with
> Tomcat?
>
> Thx
>


What are EJB

Posted by Alexandre Bouchard <ro...@mac.com>.
I've got a simple question: What are Enterprise Java Beans. I mean, what's
the difference between EJB and the beans I develop with JDK and run with
Tomcat?

Thx


RE: session error after recompile a java class....BUG?

Posted by istvan bereti <is...@kolumbus.fi>.
HI Dim,

Well thanks to think about my problem. I understand your answer but you
think if I recompile only one class this session binding error should not
happen. Well I compiled only one class which is absolutely not related to
the session but the problem still occures.
So I compiled a helper class which is not related at all with the session.
What I got is the session getAttribute() gets the bound object and it's the
right class.
But when I cast I get a ClassCastError as I said.

I checked if it's really in the session so right after bounding the object I
also fetch it. It also works. But after the first request from the client
browser, it can't cast the object bound to the session.

As I said it worked perfectly with Jserv.

If I restart TOMCAT it works again fine as long as I don't recompile any
class....

Any ideas?



-----Original Message-----
From: dim@coxless.com [mailto:dim@coxless.com]On Behalf Of Dmitri
Colebatch
Sent: Sunday, June 17, 2001 3:13 AM
To: tomcat-user@jakarta.apache.org
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?