EJB3.1,在无状态bean中发出注入数据源的问题

时间:2011-11-15 09:34:12

标签: java-ee ejb-3.1

我是新的EJB框架,我正在学习它。我正在使用Eclipse IDE上的EJB3.1和Glassfish 3作为服务器开发一个独立的应用程序。以下是代码段。

 @Remote
 public interface DataSourceRemote {
        public Connection getConnection();

    }

 @Stateless(mappedName="ejb/datasource") 
 public class DataSourceRemoteBean implements DataSourceRemote{

        @Resource(name="jdbc/datasourceDB")
        DataSource ds;

        public Connection getConnection() {

            try {

                return ds.getConnection();
            } catch (Exception e) {

                e.printStackTrace();
            }
            return null;
            }
        }

//My client code goes here
    public class Client {

        public static void main(String args[]) {

            try{
            InitialContext ctx = new InitialContext();
            DataSourceRemote bean =(DataSourceRemote)ctx.lookup("com.global.entities.DataSourceRemoteBean");                
                Connection conn = bean.getConnection();
                if(null==conn){
                    System.out.println("its null");
                }else{
                    System.out.println("connection established:"+conn.toString());
                }
            }catch (Exception e) {
                e.printStackTrace();
            }
        }
   }

当我尝试在cleint中查找jdbc/datasourceDB的JNDI时,它工作正常,但是当我尝试查看ejb/datasource并调用getConnection()时,它会抛出一个错误。下面是堆栈跟踪

    javax.ejb.EJBException: java.rmi.MarshalException: CORBA MARSHAL 1330446343 No; nested exception is: 
    org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message  vmcid: OMG  minor code: 7  completed: No
    at com.global.entities._DataSourceRemote_Wrapper.getConnection(com/global/entities/_DataSourceRemote_Wrapper.java)
    at com.global.client.Client.main(Client.java:24)
Caused by: java.rmi.MarshalException: CORBA MARSHAL 1330446343 No; nested exception is: 
    org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message  vmcid: OMG  minor code: 7  completed: No
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:267)
    at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
    at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
    at com.global.entities.__DataSourceRemote_Remote_DynamicStub.getConnection(com/global/entities/__DataSourceRemote_Remote_DynamicStub.java)
    ... 2 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message  vmcid: OMG  minor code: 7  completed: No
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
    at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
    at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
    at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
    at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
    at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
    at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
    at $Proxy24.endOfStream(Unknown Source)
    at com.sun.corba.ee.impl.encoding.BufferManagerReadStream.underflow(BufferManagerReadStream.java:128)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_1_1.java:113)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:126)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
    at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
    at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
    at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
    at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
    ... 5 more

我错过了什么吗? 有人可以帮帮我吗?

1 个答案:

答案 0 :(得分:1)

如果您正在使用远程接口,请执行独立应用程序并使用JNDI进行查找,而不是通过网络发送数据(换句话说 - 它不是本地调用)。

我认为你不应该将app server DataSource Connection发送到客户端。基本上,您应该在服务器端将数据库访问权限留给EJB,而不是将此责任泄露给客户端。

如果您正在学习EJB,那么您可以尝试使用一些简单类型(Integer,String等)。


如果涉及到您的其他问题“使用远程接口时,不应将所有容器管理对象公开给客户端”。

我认为这或多或少是真的。我认为您不应将UserTransactionDataSourceSessionContext容器管理对象公开给客户端。

但是,请记住,JPA实体也由容器管理,但在分离后 - 它可以安全地发送到客户端(并且可能在它返回时重新连接/合并)。 另一个例子可能是CDI bean。它可以由容器注入,在某些情况下,您可以将其发送到客户端并进行修改。容器无法管理CDI bean的上下文属性,但我认为您仍然可以使用它。

HTH!