Метод одного SessionBean'а возвращает RemoteInterface второго. Он выполняет lookup наподобие

account=(AccountRemote)ic.lookup("Account");

а потом

return account;

Как зделать чтобы клиент не мог находить лукапом этот Account сам, а только через первый бин? И можно ли перед return'ом вызывать методы Local интерфейса для AccountBean, ведь оба бина в пределах одной джава машини, и вызов локал метода скорее-всего возможен. Я пробовал зделать так

((AccountLocal)account).localMethod(param1);

но вылетает EJBException. Как это зделать, или у меня не правильная идеология разработки EJB?

Здравствуйте, Аноним, Вы писали:

А>Метод одного SessionBean'а возвращает RemoteInterface второго. Он выполняет lookup наподобие
А>

А>account=(AccountRemote)ic.lookup("Account");
А>

А почему не инъекцией через аннотации?

А>Как зделать чтобы клиент не мог находить лукапом этот Account сам, а только через первый бин?
Реализовать только локальный интерфейс?

А>И можно ли перед return'ом вызывать методы Local интерфейса для AccountBean, ведь оба бина в пределах одной джава машини, и вызов локал метода скорее-всего возможен. Я пробовал зделать так
Должно быть можно.

А>

А>((AccountLocal)account).localMethod(param1);
А>

А>но вылетает EJBException. Как это зделать, или у меня не правильная идеология разработки EJB?
Целиком исключение покажи.

Здравствуйте, Blazkowicz, Вы писали:

А>>Как зделать чтобы клиент не мог находить лукапом этот Account сам, а только через первый бин?
B>Реализовать только локальный интерфейс?
Понял. Протупил, клиенту же он все же нужен. Может как-то при деплойменте сконфигурять чтобы он через JNDI было доступен только локально.

Здравствуйте, Blazkowicz, Вы писали:

B>А почему не инъекцией через аннотации?

Покажите как Может если зделать это так, то вторая проблема решится тоже


А>>но вылетает EJBException. Как это зделать, или у меня не правильная идеология разработки EJB?
B>Целиком исключение покажи.

вот он

javax.ejb.EJBException: nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
        java.rmi.RemoteException: null; nested exception is: 
        java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
        java.rmi.RemoteException: null; nested exception is: 
        java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
        at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:188)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:172)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:119)
        at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:197)
        at com.is059.serverside.usermanagement.__AuthorizatorRemote_Remote_DynamicStub.toAuthorise(__AuthorizatorRemote_Remote_DynamicStub.java)
        at com.is059.serverside.usermanagement._AuthorizatorRemote_Wrapper.toAuthorise(com.is059.serverside.usermanagement._AuthorizatorRemote_Wrapper.java)
        at is059clientdebugger.Main.main(Main.java:30)
Caused by: java.rmi.RemoteException: null; nested exception is: 
        java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
        at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.java:251)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1386)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
        at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:210)
        at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:77)
        at $Proxy270.toAuthorise(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:154)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:687)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:227)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1846)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1706)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1088)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:223)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:806)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
        at com.is059.serverside.usermanagement.AuthorizatorBean.toAuthorise(AuthorizatorBean.java:43)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
        at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
        at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:203)
        ... 17 more
javax.ejb.EJBException: nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
        java.rmi.RemoteException: null; nested exception is: 
        java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
        at com.is059.serverside.usermanagement._AuthorizatorRemote_Wrapper.toAuthorise(com.is059.serverside.usermanagement._AuthorizatorRemote_Wrapper.java)
        at is059clientdebugger.Main.main(Main.java:30)

Здравствуйте, Аноним, Вы писали:

А>Покажите как Может если зделать это так, то вторая проблема решится тоже
http://docs.jboss.org/ejb3/app-server/tutorial/injection/injection.html

А>>>но вылетает EJBException. Как это зделать, или у меня не правильная идеология разработки EJB?
B>>Целиком исключение покажи.
А>вот он
А>

А>Caused by: java.lang.ClassCastException: com.is059.serverside.usermanagement._AccountRemote_Wrapper
А>        at com.is059.serverside.usermanagement.AuthorizatorBean.toAuthorise(AuthorizatorBean.java:43)
А>

Собственно исходное исключение произошло в твоем коде. EJB тут не при чем.

Здравствуйте, Blazkowicz, Вы писали:

B>Собственно исходное исключение произошло в твоем коде. EJB тут не при чем.

Когда я коментирую строчку

        ((AccountLocal)account).localMethodNameSetter("vasia");

эксэпшн не вылетает

Здравствуйте, Аноним, Вы писали:

А>Когда я коментирую строчку
А>

А>        ((AccountLocal)account).localMethodNameSetter("vasia");
А>

А>эксэпшн не вылетает
Кажется понял. Ты lookup-ом получил Remote интерфейс бина, и код обрыгался при касте к локальному интерфейсу.
Одним кастом перекючатся между локальными-удаленными вызовами не выйдет. 8) Нужно при получении интерфейса определять какой тебе нужен.

Здравствуйте, Blazkowicz, Вы писали:

B>Кажется понял. Ты lookup-ом получил Remote интерфейс бина, и код обрыгался при касте к локальному интерфейсу.
B>Одним кастом перекючатся между локальными-удаленными вызовами не выйдет. 8) Нужно при получении интерфейса определять какой тебе нужен.

Так это и был один из вопросов)) Выходит что если метод бина возвращает клиенту другой бин, то внутри метода нельзя вызывать локал методы второго бина, так как клиенту всегда нужно возвращать ремоут интерфейс. Хотя мне все-же кажеться что как-то можно. Потому что так выходит что с любым сэшин бином, если он общяется с клиентом, внутри сервера мы должны общятся тоже через рэмоут интерфейс. Я имею в виду общятся с одним и тем же экземпляром бина и на сервере и на клиенте.

Просто у меня была задумка примерно такая:
Есть стэйтфул сэшин бин. Рэмоут интерфейс предоставляет чистый интерфейс клиенту, а локал интерфейс предоставляет дополнительные служебные методы, которые могли бы вызываться только с сервера

Здравствуйте, Аноним, Вы писали:

А>Так это и был один из вопросов)) Выходит что если метод бина возвращает клиенту другой бин, то внутри метода нельзя вызывать локал методы второго бина, так как клиенту всегда нужно возвращать ремоут интерфейс. Хотя мне все-же кажеться что как-то можно. Потому что так выходит что с любым сэшин бином, если он общяется с клиентом, внутри сервера мы должны общятся тоже через рэмоут интерфейс. Я имею в виду общятся с одним и тем же экземпляром бина и на сервере и на клиенте.
Ну, по идее если ты получишь оба интерфейса в одном методе то они у тебя и будут завязаны на один экземпляр.
Просто из-за "упрощений" введенных в EJB3, сервера реализуют на своей стороне локальные и удаленные интерфейсы самостоятельно. Вот они и не совместимы.
В EJB2 вроде можно было извратится и реализовать одним бином оба интерфейса. Если сильно приспичит, то можешь сделать так же. У них вроде как обратная совместимость.


А>Просто у меня была задумка примерно такая:
А>Есть стэйтфул сэшин бин. Рэмоут интерфейс предоставляет чистый интерфейс клиенту, а локал интерфейс предоставляет дополнительные служебные методы, которые могли бы вызываться только с сервера.
Ну, оно так всегда и есть на самом деле. И это не просто твоя задумка, для этого и был разработан локальный интерфейс. Ну, и в т.ч. для лучшей производительности. ИМХО, тебе ничего не мешает обращатся на сервере к локальному экземпляру, а отдавать удаленный интерфейс. Сервер вроде гарантирует что это один экземпляр, так как дело происходит в одной сессии.

Здравствуйте, Аноним, Вы писали:

А>Так это и был один из вопросов)) Выходит что если метод бина возвращает клиенту другой бин, то внутри метода нельзя вызывать локал методы второго бина, так как клиенту всегда нужно возвращать ремоут интерфейс. Хотя мне все-же кажеться что как-то можно. Потому что так выходит что с любым сэшин бином, если он общяется с клиентом, внутри сервера мы должны общятся тоже через рэмоут интерфейс. Я имею в виду общятся с одним и тем же экземпляром бина и на сервере и на клиенте.

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