WAS9.0调用EJB3.0远程接口抛出_Remote_Stub类型转换异常求助

• 注解拼写错误：EJB类上标注的@Statless是错误拼写，正确的无状态会话Bean注解为@Stateless，注解拼写错误会导致容器无法将类识别为合法EJB，不会为目标远程接口生成对应存根和JNDI绑定。
• JNDI查找路径错误：代码中传入lookup()的JNDI_NAME_EJB不是目标EJB远程业务接口的绑定路径，而是命名空间中通用RMI远程对象的路径，返回的是通用CORBA存根而非业务接口代理。
• 类加载冲突：WAS默认采用父类加载器优先的加载策略，若客户端、服务端、WAS全局共享库中存在多份MyEjbRemote接口类，且不同份的类由不同类加载器加载，即使类全限定名一致，JVM也会判定为不同类型，无法完成强制转换，只能返回通用_Remote_Stub实例。
• 客户端上下文配置错误：独立客户端调用时未使用WAS提供的IIOP命名上下文工厂，而是使用JDK默认的CORBA命名上下文，无法识别WAS生成的EJB业务存根，只能返回通用远程存根。
• 客户端依赖缺失：客户端类路径中未引入WAS EJB客户端运行时依赖，也未引入和服务端完全一致的MyEjbRemote接口类，无法完成存根类型转换。

1. 修正EJB类注解：将类上的@Statless替换为正确的@javax.ejb.Stateless，保留@Remote(MyEjbRemote.class)注解，重新打包部署EJB应用，在WAS控制台确认目标EJB已成功启动，记录其绑定的准确远程JNDI名称，替换代码中JNDI_NAME_EJB常量的值。
2. 调整应用类加载配置：登录WAS控制台，找到部署的EJB服务端应用和调用方应用，将类加载顺序修改为父类加载器最后（应用优先），避免WAS内置的旧版本接口类覆盖应用自带的接口。同时将MyEjbRemote接口单独打包为公共jar，服务端和客户端引用同一份编译产物，保证两边接口的方法签名、版本完全一致，不要在两端分别编译存放同全限定名的接口类。
3. 修正客户端JNDI上下文配置：独立客户端调用时引入WAS9自带的EJB瘦客户端依赖com.ibm.ws.ejb.thinclient_9.0.jar，初始化上下文时指定WAS专属的初始上下文工厂，配置示例：

   import javax.naming.Context;
   import javax.naming.InitialContext;
   import java.util.Properties;
   
   public class EjbClient {
       public static void main(String[] args) throws Exception {
           Properties props = new Properties();
           props.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
           props.put(Context.PROVIDER_URL, "iiop://WAS服务IP:2809"); // 默认BOOTSTRAP_ADDRESS端口为2809
           Context ctx = new InitialContext(props);
           
           // 调试时可先打印返回对象信息，确认类型
           Object lookupResult = ctx.lookup(JNDI_NAME_EJB);
           MyEjbRemote ejb = (MyEjbRemote) lookupResult;
           // 后续业务调用
       }
   }
   

   禁止使用JDK自带的com.sun.jndi.cosnaming.CNCtxFactory作为初始上下文工厂，否则无法正确解析WAS返回的EJB存根。
4. 排查验证：若仍存在转换异常，可在强制转换前打印返回对象的类名、实现的所有接口全限定名，确认返回对象确实实现了MyEjbRemote接口，排除JNDI路径配置错误、EJB未正常注册的问题。

内容的提问来源于stack exchange，提问作者Luciana Oliveira