This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Classloader problem with SimpleRemoteStatelessSessionProxyPage Title Module

the setup is the following: Websphere 5.0 Test environment, the EJB is in a separate EAR (EAR 1) and the client
code is in a separate EAR (EAR 2). I CAN call methods which have just simple parameters (like Integer etc.).

I think I figured out what the problem is, Spring does not use PortableRemoteObject.narrow(). It looks like the
narrow method changes the classloader for my stub:

If I just look up the home stub in the jndi tree (as spring does) and do not use the narrow method, then the
classloader for my stub is EAR 1. when I use narrow the classloader for the stub is EAR2 (just try getClass().getClassloader()).
Now if spring tries to find the method doit(Person aPerson) it can't find the method because it compares persons
with different classloaders (i.e. it compares the person from EAR1 with the Person from EAR2).

So it looks like it is a bug in Spring, i.e. that no narrowing of the stub is used. I don't know really how this
can be fixed as the SimpleRemoteStatelessSessionProxyFactoryBean does not know the home class (everything is done via
reflection).

Interesting issue. Indeed the missing narrowing could cause other problems as well. I'm currently using this mechanism also, furtunately without negative effects (yet).

I suppose you create a JIRA issue for this.

Regards,
Andreas

P.S.: Maybe a solution could be the following: To cast the Object to EJBHome and determine the actual class with EJBHome#getEJBMetaData().getHomeInterfaceClass(). This way the narrowing could be performed using the correct class.
I'm just not 100% sure if the direct cast to EJBHome is allowed by the EJB-specification. However it seems to be better than the current situation.

Comment

Just to improve my suggested solution:
Of course one can narrow the Object retrieved from the lookup to EJBHome (which should be safe) and than proceed as described. This should work in any case (with the added benefit to find out if the Object stored in the JNDI location is in fact no EJBHome).