I found when the JDK was changed from 1.4.0, as above to 1.3.1_06 the problem disappeared. Surely this points to a bug in JBoss 3.0.2 or an incompatibility between it and JDK 1.4.0?
Can someone clarify please?
I would still appreciate some clarification about subclassing EJBs, particularly subclassing of home and local home interfaces. Is it permissible to subclass home and local home interfaces under the EJB 2.0 spec?
Thanks in anticipation
Yes, it is permissible.
Your CCE is probably due to one of two problems.
1) You are still referencing an old class after a
redeployment, e.g. you have separate wars and ejb jars
but you only redeploy the ejb. The war has an old
2) You have a jndi.properties somewhere and are
using PortableRemoteObject.narrow for a "local"
invocation. The 1.4 version of PortableRemoteObject
caches class instances (breaking hot deployment).
This is only a problem with the jndi.properties causing
the request to go over rmi.
Thank you for your response Adrian.
Concerning the CCE:
With respect to 1) above, I do have one WAR that stores references to EJBs and there are two JARs in my application, but WAR and JARs are packaged in one EAR, so I presume that the scenario of 1) above cannot occur. Is that correct?
Point 2) above seems to fit the symptoms better. I have a jndi.properties file in the default/conf directory (and it is the default server that is being used), but it has only the default settings in it, I have not modified it at all. Also JBoss, the database, the application and the JVM are all on the same machine at present. And within the application there is one remote interface that is invoked using the PortableRemoteObject, which is where the CCE occurred. However, there is one point that I do not understand, and that is the CCE occurred even when the remote interface was replaced with a local one and the PortableRemoteObject not used. Does that make any sense to you?
Thanks and regards
No it does not.
The jndi.properties in default/conf does not use RMI
and so cannot hit the PortableRemoteObject.narrow cache.
Can you try it with 3.0.4?
I know from my own experience there was a bug in
Jetty for 3.0.2 relating to WEB-INF/lib (although
not this exact problem).
If you are redeploying a new class and
everything that references the class you should not
Thanks for your reply.
Previously I had downloaded 3.0.4, as that was to be the next thing I tried after JDK 1.3.1, but I have put off going down that route as I am under pressure to complete my application development. However if it were important for you to know the result, I could try and find the time to test my application with 3.0.4.
I am getting the same Class Cast Exception.
I am using JDK 1.4 and have tried various combinations of JBoss and Tomcat and still get the problem. I too am using the default settings of the server and not going over RMI.
I have tried JBoss 3.0.4 with JDK 1.4 and the problem is still there.
Same with me. I also get a class cast exception, when I try to "redeploy" during JBOSS is runnning. The first Time I call a method on my Session Bean I get a class cast exception.
I´ve got two jar files, one for my entity beans and one for my session beans.
My beans are working if I shutdown and then restart JBOSS.
I´m using J2SDK 1.4.1 and JBOSS 3.0.4
I've committed a fix for this in 3.0.5RC1
available from CVS
Despite the name of the class there is no jboss
To use the class, put it in your JBOSS_CLASSPATH set by
run.sh/run.bat and add the following property
This does not solve the problem of classes from one jar
holding old references to a class from a redeployed jar.
Use a in jboss.xml to solve that problem.
I can't seem to get this file from CVS on SourceForge - Do I need to have some CVS client software running on my machine ?
Is there any way I can get hold of this file without using CVS ?
I'm still struggling with this Class Cast Exception. I don't have a jndi.properties file in the jar file with my EJB's and am using the default jndi.properties file from default/conf which doesn't use RMI.
The fix that's available on SourceForge is presumably only for calls going over RMI which mine are not.
This class cast exception only occurs after a hot deployment. Stopping the server and restarting it makes the CCE go away.
Can anyone help ?
This has been committed onto the main branch now
so it has moved out of the attic. Here is the
I am currently having this same CCE when a servlet attempts to gain a remote connection back to a redployed session bean. I am running J2SDK 1.4.2 and JBoss 3.2.3.
The scenario is a single .EAR file with a .WAR and a .JAR contained. It is a servlet in my .WAR that is attempting to access a remote in the .JAR. The first connect works just fine, then I redeploy the entire .EAR and get the CCE when I call
The previous messages in this thread pretty much describe the same problem, but where posted a long while ago and about an older version of JBoss. Is there any update or new information regarding this problem?