Even More Challenging Class Loading problem

[bono]

Hi,

I have the same problem as the one yusdi described in his posting from Oct 9th, although in a different context.

I have an EAR containing EJBs and a WAR, and also two MBeans that access some of the EJBs.

I had a depends problem but I managed to find a solution for it in the newsgroups here - just had to add some depends tags to the mbeans.

Now the problem that is left is on re-deployment of the EAR containing the EJBs. When the MBeans try to access the EJBeans they get ClassCast or Class not compatible exceptions. This is despite the depends tags - JBoss does stop the MBeans & start them again but it does not re-deploy them.

The solutions to yusdi's problem does not apply here because I am not using a classloader directly - I am just importing the classes & directly accessing them from my code (statically).

Most probably I could package the MBeans (currently .sar archives) into the EAR to force them being redeployed, or manually re-deploy them through the JMX interface to fix that.

I am not very interested in those solutions however, becaue they would make it too complex to redeploy the EAR -

* If I package the MBeans into the EAR, the file would grow too large & upload to our production server would take too long.
* If I have to manually redeploy the MBeans I lose the one-step quick update process that I am enjoying right now.

So I was wondering if there is some solution to the problem - it persists in both JBoss 3.0.3 and 3.2.0beta. Would it be possible to force the MBeans to be redeployed on redeployment of the EAR? Or is it possible to force the java runtime to use the proper classloader?


Nik

[bono]

P.S. Actually herer are the two errors I get:

----------------------------------------------------

java.lang.LinkageError: loader constraints violated when linking admintool/ejb/stateless/AccessManager class
at rtb.server.RealTimeBidder.authenticateAdministrator(RealTimeBidder.java:83)

Here is the code:

package rtb.server;

//...

import admintool.ejb.stateless.*; // Package containing AccessManagerHome

//...

// Line 83
AccessManager am = ((AccessManagerHome) EJBHelper.getHome("AccessManagerHome", AccessManagerHome.class)).create();

//...

----------------------------------------------------

java.lang.ClassCastException
at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:291)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:132)
at auctionengine.auctionlayer.EJBHelper.getAuctionFromEJB(EJBHelper.java:192)

And the code:

package auctionengine.auctionlayer;

//...

import admintool.ejb.stateless.OnlineAuctionsManagerHome;

//...

// Line 191
Object ref = jndiContext.lookup("OnlineAuctionsManagerHome");
// Line 192
OnlineAuctionsManagerHome home = (OnlineAuctionsManagerHome) PortableRemoteObject.narrow(ref, admintool.ejb.stateless.OnlineAuctionsManagerHome.class);

//...

[adrian.brock]

Are you using java 1.4?
Does it work if you remove the narrow operation
and do a straight cast?

Object ref = jndiContext.lookup("OnlineAuctionsManagerHome");
OnlineAuctionsManagerHome home = (OnlineAuctionsManagerHome) ref;

Regards,
Adrian

[bono]

I am using Java 1.3.1_05, but I tried 1.4.1 - same result.
When i remove the narrow operation I get a classcast exception:

java.lang.ClassCastException: $Proxy175
at auctionengine.auctionlayer.EJBHelper.getAuctionFromEJB(EJBHelper.java:192)

----------------------------------

I did some debugging & found out that Java uses correctly the UniformClassLoader (or whatever jboss's classloader is called) when it does its internal classloading.

However the problem is that the classes are not "unloaded" on redeploy of the EAR. I tried clearing all references I have & making an explicit System.gc() call in my destroyService() method, hoping that this would unlink the EJB classes - no luck, it did not help.

nik

[adrian.brock]

If that is true, it is a bug.

I had heard of problems with narrow on 1.4 because
of the JVM caching classes in the RMI layer, but
I'm pretty sure this was fixed.

Can you create a simple test that reproduces the
problem and post it as a bug at
www.sf.net/projects/jboss

Regards,
Adrian

[aradka]

Was this ever fixed. I couldn't find anything matching it in the big list?

I am having a similar (yet slightly different) problem. I didn't want to post all the details in a new thread, if this has been fixed in a later release (I am using jboss-3.0.3_tomcat-4.1.12).

Thx,
Alex