Classloader problem with SimpleRemoteStatelessSessionProxy

[reinhardtp]

I have the following problem, my remote EJB has one method, with a custom parameter:


void doit(Person aPerson);


If I try to execute this method with the SimpleRemoteStatelessSessionProxyFactoryBean I get the following exception:

[Servlet Error]-[EJBTest]: java.lang.NoSuchMethodException: doit
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getMethod(Class.java:928)
at org.springframework.remoting.rmi.RmiClientIntercep torUtils.doInvoke(RmiClientInterceptorUtils.java:1 02)
at org.springframework.ejb.access.SimpleRemoteSlsbInv okerInterceptor.doInvoke(SimpleRemoteSlsbInvokerIn terceptor.java:76)
at org.springframework.ejb.access.AbstractRemoteSlsbI nvokerInterceptor.invoke(AbstractRemoteSlsbInvoker Interceptor.java:78)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :144)
at org.springframework.aop.framework.JdkDynamicAopPro xy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy3.doit(Unknown Source)
at jdbcTest.EJBTest.doGet(EJBTest.java:70)



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).

What Spring is implicitly trying to do is the following:

(PersonMgr) mgr = (PersonMgr) initialContext.lookup("java:comp/env/ejb/PersonMgr");

which is not really allowed (direct cast).


Peter

[Andreas Senft]

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.

[Andreas Senft]

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).

Regards,
Andreas

[Andreas Senft]

I added the JIRA issue with a reference to this thread. It has the number SPR-696. I'm also very interested in getting this fixed.

Regards,
Andreas

[rjelli]

I've got exactly the same problem (see stack trace below). Our setup is almost identical, meaning 2 ear files (one with the web module, the other one with the ejb module) on 2 different servers.

As we were using 1.2.5, I downloaded and installed 1.2.6, hoping the problem would be fixed in this new release, but that doesn't seem to be the case.

The only way I found to resolve this problem is to do the lookup myself in the web layer.

Do you have any idea if this problem will be addressed in one of the future releases ?

Thanks,

Roland Jelli


the stack trace is:

Caused by: null
at org.springframework.remoting.rmi.RmiClientIntercep torUtils.doInvoke(RmiClientInterceptorUtils.java:1 10)
at org.springframework.ejb.access.SimpleRemoteSlsbInv okerInterceptor.doInvoke(SimpleRemoteSlsbInvokerIn terceptor.java:75)
at org.springframework.ejb.access.AbstractRemoteSlsbI nvokerInterceptor.invoke(AbstractRemoteSlsbInvoker Interceptor.java:114)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :144)
at org.springframework.aop.framework.JdkDynamicAopPro xy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy7.getRules(Unknown Source)
at com.viveo.hobm.web.jsf.rules.BBRules.getRules(BBRu les.java:149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java(Compiled Code))
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java(Compiled Code))
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compil ed Code))
at com.sun.faces.el.PropertyResolverImpl.getValue(Pro pertyResolverImpl.java:79)
... 60 more
Caused by: java.lang.NoSuchMethodException: com.viveo.hobm.ejb.services._RuleManager_Stub.getR ules(com.viveo.hobm.domainmodel.HobmRule)
at java.lang.Class.getMethod(Class.java(Compiled Code))
at org.springframework.remoting.rmi.RmiClientIntercep torUtils.doInvoke(RmiClientInterceptorUtils.java:1 02)
... 72 more

[Andreas Senft]

The original issue has been already resolved for version 1.1.5

See here
Did you try the EJBHome configuration?

Regards,
Andreas

[rjelli]

excuse me, but what exactly do you mean by "EJBHome configuration" ?

my Spring context file on the web layer contains:

<bean id="ruleServices" class="org.springframework.ejb.access.SimpleRemote StatelessSessionProxyFactoryBean">
<property name="jndiName">
<value>java:comp/env/ejb/HobmRuleManager</value>
</property>
<property name="businessInterface">
<value>com.viveo.hobm.services.RuleServices</value>
</property>
</bean>

and the bean is referred to via a JSF managed property, resolved by Spring. The faces-config file looks like this:

<faces-config>

<application>
<variable-resolver>org.springframework.web.jsf.DelegatingVar iableResolver</variable-resolver>
</application>

<managed-bean>
<description>This bean is a rule list bean.</description>
<managed-bean-name>rules</managed-bean-name>
<managed-bean-class>com.viveo.hobm.web.jsf.rules.BBRules</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>ruleServices</property-name>
<value>#{ruleServices}</value>
</managed-property>
</managed-bean>
...
</faces-config>

[Andreas Senft]

I mean the configuration of the "homeInterface" property of your proxy factory. This was the fix mentioned in the bug description (see the link in my last posting).

Regards,
Andreas