Yes. I found a workaround on the dev-list, by setting the classloader before lookup,
but it should be fixed.

Hello,

I'have kind off the same problem with any cast to a home or remote object i get exceptions like this all the time:


java.lang.ClassCastException: $Proxy3
at den.ejbdom.client.EJBDomSessionClient.(EJBDomSessionClient.java:24)
at den.ejbdom.test.EJBDomTEST.testUNK_with_no_valid_tpn_tpe(EJBDomTEST.java:25)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:166)
at junit.framework.TestCase.runBare(TestCase.java:140)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:131)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at junit.swingui.TestRunner$17.run(TestRunner.java:644)

i don't really understand about setting the classloader before lookup, what am i supposed to set ?

Thankx

oops that last one was just for junit swingui. but the problem still remains for entity beans. I get the cast exception at create(somekey) but the records are written into the database so everything seems to be fine if it wasn't for the stacktrace??

This is what I did:

// FIX because of bug i JBOSS
ClassLoader oldClass = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(RegistrarHome.class.getClassLoader());
//

Properties prop = new Properties();
prop.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory" );
prop.setProperty("java.naming.provider.url", "127.0.0.1:1099" );

try {
InitialContext ctx = new InitialContext( prop );
Object o = ctx.lookup("something");
RegistrarHome regHome = (RegistrarHome) PortableRemoteObject.narrow( o, RegistrarHome.class );
Registrar registrar = regHome.create();
return registrar;
}
finally {
Thread.currentThread().setContextClassLoader(oldClass);
}


It removed this problem (but I think you have to do it on
all lookups.....) and introduced this bug:
http://main.jboss.org/thread.jsp?forum=47&thread=8373

so I ended up going back to jboss alpha from Jan 16 (08.30 AM), which works with this patch:
http://main.jboss.org/thread.jsp?forum=46&thread=7393&message=378893

Forgot to say that I encountered this problem on the new jboss 3.0 beta.

Marius

I encountered a similar problem (jboss 2.4.3) after bean passivation when I stored a reference to a Stateful SessionBean in another Stateful SessionBean and posted it to the jboss userlist on January 17. 2002. But I didn't get a satisfactory answer:

> Hello,
>
> I want to store references to stateful sessionbeans in a
> Hashtable of a
> stateful sessionbean.
> I tried to store the beanhandle and got a weird behavior:
> The classname of the stored objects has been
> 'org.jboss.ejb.plugins.jrmp.interfaces.StatefulHandleImpl'.
> When I get the object from the Hashtable normally the
> classname is correct,
> but when the bean has been passivated and activated the
> classname has been
> something like '$Proxy3'
> and I get a ClassCastException on the cast to a Handle.
>
> I know the classname of the bean references in jboss is
> somthing like $Proxy
> (to see sometimes in Exception printStackTrace ...). It looks
> like that
> through passivation / activation the handles have been restored to the
> remoteinterfaces of the beans ....
>
> What's going on here ?
> How should I store bean references: as remoteinterface or handle ?
>
> Annegret

I attach a zip-file with code, jar and server.log of a simple sample.