Announcement Announcement Module
Collapse
No announcement yet.
Classloader problem with SimpleRemoteStatelessSessionProxy Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Classloader problem with SimpleRemoteStatelessSessionProxy

    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

  • #2
    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


    • #3
      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

      Comment


      • #4
        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

        Comment


        • #5
          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

          Comment


          • #6
            The original issue has been already resolved for version 1.1.5

            See here
            Did you try the EJBHome configuration?

            Regards,
            Andreas

            Comment


            • #7
              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>

              Comment


              • #8
                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

                Comment

                Working...
                X