2011-11-15 14 views
0

私は新しいEJBフレームワークであり、学習中です。 Eclipse IDE上でEJB3.1を使用し、サーバーとしてGlassfish 3を使用してスタンドアロンアプリケーションを開発しています。以下はコードスニペットです。EJB3.1は、ステートレスBeanにデータソースを注入します。

@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(); 
      } 
     } 
    } 

私はJNDIはそれが正常に動作しますが、私はejb/datasourceに見上げると(のgetConnectionを呼び出すをしようとするときcleintにjdbc/datasourceDBのためのルックアップ実行しようと今まで)それは私にエラーがスローされます。以下はスタックトレースです

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 

何か不足していますか? 誰も助けてくれますか?

+0

Application Serverで取得したDataSource接続を、ワイヤでクライアントに送信していますか? –

+0

電信送付の意味を詳しく教えてください。私は初めてそれを聞いています。 – Patton

+0

コードをどのように実行していますか?あなたが投稿したファイルは、あなたがアプリケーションサーバーにデプロイすると同時に、スタンドアロンアプリとして実行するファイルです。 –

答えて

1

リモートインターフェイスを使用している場合は、スタンドアロンアプリケーションを実行し、JNDIを使用して、ワイヤを介してデータを送信するよりもルックアップを実行します(つまり、ローカルコールではありません)。

私はあなたがアプリケーションサーバーDataSource Connectionをクライアントに送るべきではないと思います。基本的には、この責任をクライアントにリークさせるのではなく、サーバー側のEJBへのデータベースアクセスを残す必要があります。

単純な型(整数、文字列など)で試すことができます。それはあなたの他の質問に来る場合


は「すべてのコンテナの管理対象オブジェクトは、リモート・インタフェースがを使用している際にクライアントに公開すべきではありません」。

私は多かれ少なかれ真実だと思います。 UserTransactionDataSourceまたはSessionContextコンテナ管理オブジェクトをクライアントに公開する必要はありません。

ただし、JPAエンティティもコンテナによって管理されますが、デタッチ後は安全にクライアントに送信できます(また、戻ったときに再接続/マージされる可能性があります)。
もう1つの例はCDI Beanです。それはコンテナによって注入することができ、場合によってはそれをクライアントに送信して変更することができます。コンテナはCDI Beanのコンテキスト上の性質を管理することはできませんが、あなたはまだそれを使用できると思います。

HTH!

関連する問題