Bugs item #666662, was opened at 2003-01-12 10:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666662&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Adrian Brock (ejort)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
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
----------------------------------------------------------------------
Comment By: Qing Gong (gongqin)
Date: 2003-01-27 15:53
Message:
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.
----------------------------------------------------------------------
Comment By: Adrian Brock (ejort)
Date: 2003-01-16 04:29
Message:
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
----------------------------------------------------------------------
Comment By: jb (jbgaden)
Date: 2003-01-16 04:00
Message:
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.
----------------------------------------------------------------------
Comment By: Loz (lozzer)
Date: 2003-01-12 16:39
Message:
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
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2003-01-12 13:42
Message:
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().
----------------------------------------------------------------------
Comment By: Adrian Brock (ejort)
Date: 2003-01-12 12:36
Message:
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
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666662&group_id=22866
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
