Menu
▾
▴
#1042 Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.<init>(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
================================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
================================================================================
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
Logged In: YES
user_id=9459
The 3.0.5RC1 binary release was built with 1.3 so
it does not include the 1.4 RMIClassLoader workaround.
It won't compile on 1.3 :-(
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss-
system/src/main/org/jboss/system/JBossRMIClassLoader.jav
a?annotate=1.1.2.1
If you build the source release on 1.4 it will be included
in run.jar
Alternatively, download the above class, compile it
and add it to the classpath.
Ideally, you should not be using the RMI layer
when you are in the same VM.
Regards,
Adrian
Logged In: YES
user_id=175228
This can be avoided by not including a PROVIDER_URL in
the env, or equivalently using the default InitialContext().
Logged In: YES
user_id=686442
Thanks for the tip. I downloaded the source to the class
indicated, compiled and added it to run.jar, and now things
seem to be fine.
As is happens, I did try and compile the whole thing from
the source, but I got a lot of compile errors. Were there
some bits missing from jboss-3.0.5RC1-src.tgz? The first
error was:
compile-classes:
[javac] Compiling 419 source files to
/home/loz/src/jboss-3.0.5RC1-src/jmx/output/classes
[execmodules]
/home/loz/src/jboss-3.0.5RC1-src/jmx/src/main/org/jboss/mx/modelmbean/ModelBase.java:43:
package org.jboss.mx.persistence does not exist
[execmodules] import org.jboss.mx.persistence.NullPersistence;
There is no NullPersistence source in the tarball that I
downloaded.
Finally (if you don't mind giving out free coding tips!),
You mentioned not using the rmi layer if I was in the same
VM. Would you suggest attempting a standard cast, before
doing a narrow call, or an environment setting to
distinguish between the two. Or maybe you have something
cleverer in mind?
thanks again,
Loz
Logged In: YES
user_id=552715
Using Jboss version from Jboss-3.0.5_jdk1.41.zip, I get
still CCE when I redeploy an EJB.
Is there any settings or trick to do to get rid off those CCE ?
As I read this thread it seems to work so I'm very surprised
that it does not work for me.
I'm runing Jboss under Lunix RH 7.3 / jdk sun 1.4.1_01
Thanks.
Logged In: YES
user_id=9459
Make sure the "client" of the EJB is recycled
along with the redeployed EJB jar, otherwise the client will
hold a reference to the old class.
i.e. use an ear or a <depends> in jboss.xml
Or move the interfaces to a separate jar and only redeploy
the implementations.
Or use the ByValueInvokerInterceptor instead of
InvokerInterceptor in the <client-interceptors>, but that
has a performance penalty and won't work for
local interfaces.
Or use reflection to access the EJB. :-)
This bug was about ear redeployment where everything is
recycled together, but the VM was caching interface
classes.
I'm closing this as fixed.
Regards,
Adrian
Logged In: YES
user_id=698389
In my case, I am re-deploying an EJB (mid-tier, client to a
remote EJB). The real client is a command line java app,
which exits after calling my EJB. Do I need to redeploy the
remote EJB (server to my EJB). I hope not.
Thanks.
Logged In: YES
user_id=9459
If you have a question about deployment use
www.jboss.org/forums
If you think you have found a bug open a new report.
In either case, please provide versions jboss/jvm/os,
a stack trace, deployment descriptors,
packaging information or a simple example
that reproduces the problem.
Regards,
Adrian