EJB3.1, проблема внедрения источника данных в bean-компонент без сохранения состояния - PullRequest
0 голосов
/ 15 ноября 2011

Я новый EJB-фреймворк и изучаю его. Я разрабатываю отдельное приложение, использующее EJB3.1 в Eclipse IDE и 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();
            }
        }
   }

Когда я пытаюсь найти JNDI для поиска jdbc/datasourceDB в cleint, он работает нормально, но когда я пытаюсь найти 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 Ответ

1 голос
/ 15 ноября 2011

Если вы используете удаленный интерфейс, запустите автономное приложение и используйте JNDI для поиска, а не для отправки данных по проводам (другими словами - это не локальный вызов).

Не думаю, что вам следует отправлять соединение с сервером приложений на сервер приложений клиенту.По сути, вам следует оставить доступ к базе данных для вашего EJB на стороне сервера, а не передавать эту ответственность клиенту.

Если вы изучаете EJB, то вы можете попробовать использовать какой-нибудь простой тип (Integer, String и т. Д.).).


Если возникает другой вопрос " Все управляемые контейнерами объекты не должны быть доступны клиенту при использовании удаленного интерфейса ".

Я думаю, это более или менее верно.Я не думаю, что вы должны предоставлять клиенту управляемые объекты контейнера UserTransaction, DataSource или SessionContext.

Однако помните, что сущность JPA также управляется контейнером, но после отсоединения - ее можно безопасно отправить клиенту (и, возможно, повторно подключить / объединить, когда она вернется).
Другой пример можетбыть бобом CDI.Он может быть введен контейнером, а в некоторых случаях вы можете отправить его клиенту и изменить его.Контейнер не может управлять контекстной природой bean-компонента CDI, но я думаю, что вы все еще можете его использовать.

HTH!

...