EAR, EJB3 - Local / Remote ?
Kornel
mam drobny problem z aplikacją i trochę się pogubiłem - wiem, że
jeśli aplikacje chodzą w obrębie jednej VM, to wtedy ejb nie musi 'być
zdalny' (konkretnie chodzi o @Remote, taki bean wystarczy jak ma
interfejs @Local) a gdy chcemy dostać się do SLSB z innej VM, to
musimy zrobić ku temu interfejs @Remote.
Ok, teraz mam aplikację w jednym EAR, serwer Glassfish 2.1, a w tej
aplikacji - beans.jar z ejb i webapp.war - aplikacja web'owa, spring.
Chciałbym z tej aplikacji dostać się do SLSB z beans.jar poprzez jndi.
Odkąd przesiadłem się na spring 2.5 nie udaje mi się to srogo, ale
zanim zacznę kombinować, chciałem wiedzieć czy w tak skonstruowanym
EAR, to wystarczy przecież, że SLSB z beans.jar mają interfejsy
@Local, prawda? Myślałem, że cały EAR chodzi w jednej VM. Z drugiej
strony jeśli one są local, to żadna nazwa jndi chyba się nie tworzy,
prawda (https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html) ?
Trochę się pogubiłem w teorii.
Dzięki za podpowiedzi jak to tak naprawdę powinno być :)
Pozdrawiam,
Kornel
Witold Szczerba
> Hej,
> mam drobny problem z aplikacją i trochę się pogubiłem - wiem, że
> jeśli aplikacje chodzą w obrębie jednej VM, to wtedy ejb nie musi 'być
> zdalny' (konkretnie chodzi o @Remote, taki bean wystarczy jak ma
> interfejs @Local) a gdy chcemy dostać się do SLSB z innej VM, to
> musimy zrobić ku temu interfejs @Remote.
Tak, to jest mniej więcej prawda.
> Ok, teraz mam aplikację w jednym EAR, serwer Glassfish 2.1, a w tej
> aplikacji - beans.jar z ejb i webapp.war - aplikacja web'owa, spring.
> Chciałbym z tej aplikacji dostać się do SLSB z beans.jar poprzez jndi.
> Odkąd przesiadłem się na spring 2.5 nie udaje mi się to srogo, ale
> zanim zacznę kombinować, chciałem wiedzieć czy w tak skonstruowanym
> EAR, to wystarczy przecież, że SLSB z beans.jar mają interfejsy
> @Local, prawda? Myślałem, że cały EAR chodzi w jednej VM. Z drugiej
> strony jeśli one są local, to żadna nazwa jndi chyba się nie tworzy,
> prawda (https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html) ?
> Trochę się pogubiłem w teorii.
Jeśli moduły są wewnątrz jednego 'Enterprise Archive" (EAR) to
komunikacja z session bean po interfejsie lokalnym jest najwłaściwszym
rozwiązaniem. Odnośnie JNDI: lokalny bean sesyjny nie rejestruje się w
globalnym JNDI. Jeśli komponent A chce mieć referencję do komponentu B
po interfejsie lokalnym to musi zadeklarować to. Sposobów jest kilka,
najprostszy jest taki:
public class ABean implements ... {
@EJB BLocal bBean;
jakaśMetoda(...) {
zrób_coś.z(bBean)..
}
}
W powyższym przykładzie "ABean" deklaruje, że będzie potrzebował
referencji do B po interfejsie lokalnym. Inna droga jest taka:
@EJBs({
@EJB(name="mojaNazwa", beanName="BBean", beanInterface=BLocal.class)
// po przecinku można wymieniać więcej @EJB...
})
public class ABean implements ... {
@Resource
private SessionContext ctx;
jakaśMetoda(...) {
BLocal bBean = (BLocal) ctx.lookup("mojaNazwa");
}
}
Jak widać wewnątrz metody możemy wyciągnąć referencję do dowolnego
obiektu zarejestrowanego w sekcji @EJBs podając jego nazwę zgodnie z
atrybutem "name".
Ostatni sposób jaki znam to deskryptor aplikacji (plik XML) w którym
możemy to samo co za pomocą przykładu powyżej zrobić, tzn. w metodzie
pozostaje jak powyżej, a wywalamy całe to @EJBs wstawiamy odpowiednik
do pliku XML.
Podejrzewam, że byś chciał uzyskać coś innego, tzn. dostęp do beanów
sesyjnych w springowych komponentach (które nie są częścią systemu
EJB). Jeśli tak... to nie wiem jak można by to zrobić (nigdy nie
używałem Spring'a). Z tego co się orientuję, wg specyfikacji EJB (do
3.0 włącznie) nie da się uzyskać referencji do lokalnego SLSB/SFSB z
kontekstu, który nie należy do innego elementu EJB, który go nie
zadeklarował.
Podejrzewam, że da się to jakoś ominąć... np. Spring mógłby mieć coś w
rodzaju podkładki EJB, dzięki czemu miałby dostęp do kontekstu z np.
lokalnymi EJB, ale z tego co wiem, to JNDI jest ustalany raz podczas
instalacji aplikacji, a Spring zależności może ustalić dopiero po
uruchomieniu... więc nie wiem jak by to mogło działać. Na pewno o
wiele łatwiej jest w drugą stronę, tzn. dostać coś od Springa z
poziomu EJB.
--
Witold Szczerba
Kornel
>
> Jeśli moduły są wewnątrz jednego 'Enterprise Archive" (EAR) to
> komunikacja z session bean po interfejsie lokalnym jest najwłaściwszym
> rozwiązaniem. Odnośnie JNDI: lokalny bean sesyjny nie rejestruje się w
> globalnym JNDI. Jeśli komponent A chce mieć referencję do komponentu B
> po interfejsie lokalnym to musi zadeklarować to. Sposobów jest kilka,
dzięki za opis :)
> Podejrzewam, że byś chciał uzyskać coś innego, tzn. dostęp do beanów
> sesyjnych w springowych komponentach (które nie są częścią systemu
> EJB).
bingo. Co ciekawe, udało się (plus minus). Wklejam poniżej, jakby ktoś
był zainteresowany, konfigurację springa (wersja 3.0.0.M2).
Co ciekawe, dostaję wyjątek od Glassfisha, ale Spring mimo to daje
radę. Jak mi się to uda rozwiązać, to będę bardzo szczęśliwy (nie
lubię takich wyjątków gdzieś po drodze zostawiąc, nic dobrego z tego
nie może wyniknąć), ale na razie stety/niestety wszystko działa.
Nawiązując do tego co pisałeś wcześniej, jak Spring to robi? Nie
jestem też pewny czy zrozumiałem - czyli jeśli mam interfejs lokalny,
to bean się nie rejestruje w żadnym 'katalogu' JNDI (globalnym na
pewno nie, istnieje coś takiego jak lokalny?). Wpis w web.xml
przypisuje po prostu klasę z <local>..</local> pod nazwę podaną w <ejb-
ref-name>...</ejb-ref-name> ?
Dzięki za pomoc,
Kornel.
Poniżej kod.
wyjątek (do zignorowania, chyba):
javax.naming.NameNotFoundException: xxxx not found
at com.sun.enterprise.naming.TransientContext.doLookup
(TransientContext.java:216)
web.xml:
<ejb-local-ref id="ejb_testmanager">
<ejb-ref-name>ejb/TestManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>yyy.test.TestManager</local>
</ejb-local-ref>
applicationContext.xml
<jee:jndi-lookup id="xxx" jndi-name="java:comp/env/ejb/TestManager"/>
klaska, kontroler Springa:
@Controller
public class TestUIController {
...
private TestManager testManager;
@RequestMapping("/")
public String indexHandler() {
System.out.println("no prosze: " + testManager);
if (testManager != null) {
System.out.println("jedziemy");
testManager.GenerateSomeData();
}
return "index";
}
...
@Resource(name="xxxx")
public void setTestManager(TestManager testManager) {
this.testManager = testManager;
}
}
Witold Szczerba
> Nawiązując do tego co pisałeś wcześniej, jak Spring to robi? Nie
> jestem też pewny czy zrozumiałem - czyli jeśli mam interfejs lokalny,
> to bean się nie rejestruje w żadnym 'katalogu' JNDI (globalnym na
> pewno nie, istnieje coś takiego jak lokalny?). Wpis w web.xml
> przypisuje po prostu klasę z <local>..</local> pod nazwę podaną w <ejb-
> ref-name>...</ejb-ref-name> ?
Tak, lokalny session bean się sam nigdzie nie zarejestruje, w
przeciwieństwie do zdalnego, który jest dostępny globalnie w JNDI
całego kontenera EJB.
Niestety nie znam się ani na Spring'u ani na aplikacjach webowych
(servlety/JSP/JSF), ale z tego co widzę to masz właśnie w web.xml
zarejestrowany bean z interfejsem yyy.test.TestManager. Takie coś
powinno wystarczyć Springowi, żeby z tego webowego kontekstu aplikacji
sobie beana wyciągnąć (mam na myśli kontekst, którego dotyczy taki
web.xml - sorry za te lekkie gdybanie, ale jak pisałem, otarłem się o
tematy webowe tylko teoretycznie i w zasadzie przypadkiem, muszę się
za to zabrać :).
miluch
Witek a mógłbyś mi napisać co rozumiesz pod nazwą globalne jndi?
Moja wiedza na temat EJB skończyła się na wersji 2.1. Z tego co mi się
wydawało to przy definiowaniu EJB podawało się nazwy JNDI interfejsu
lokalnego i zdalnego(w przypadku gdy chcieliśmy mieć dostęp do EJB po
local i remote).
Nazwy te miałyby być zdefiniowane w "globalnym JNDI" i dostęp do beana
byłby za pomocą lookup("nazwa_JNDI_interfejsu_lokalnego") lub lookup
("nazwa_JNDI_interfejsu_zdalengo").
Z 2 strony gdy chcemy odwołac się do danego EJB z innego EJB lub
servletu/JSP to można zdefiniować w odpowiednich plikach (dla servlet/
jsp to będzie web.xml a dla EJB to jakis tam ejb-jar.xml) referencje
do tego EJB za pomocą:
ejb-ref/ejb-local-ref plus dodatkowo określić (jaka jest nazwa pliku i
jak wygląda takie określenie zależy od kontenera) jak "globalna nazwa
JNDI" mapuję się na element występujący w ejb-ref-name/ejb-local-ref-
name.
W ten sposób mapuję sobie interfejs zdalny/lokalny beana do "lokalnego
nazwy JNDI" i odwołuje się za pomocą lookup("java:comp/env/...").
Z tego co pamiętam w Websphere tak właśnie to działalo...
W takim razie moja zrozumienie nie do końca pasuję do stwierdzenia, że
lokalne EJB nie rejestrują się w globalnym JNDI ...
@Kornel:
Spring w przestrzeni nazw jee ma dedykowany element do odwolywania sie
do stateless EJB: local-slsb i remote-slsb.
pzdr miluch
Witold Szczerba
> Witam
>
> Witek a mógłbyś mi napisać co rozumiesz pod nazwą globalne jndi?
Chodzi mi o globalny kontekst, dostępny przez interfejs
javax.naming.Context, w przeciwieństwie do jego gałęzi java:comp/env/*
lub po prostu EJBContext (SessionContext dla SFSB/SLSB czy
MessageDrivenContext dla MDB), który jest kontekstem danego bean'a:
The EJBContext interface provides an instance with access to the
container-provided runtime context of an enterprise Bean instance.
Tzn. jeśli mamy w ENC danego bean'a dostępne coś pod nazwą: xyz to
możemy się do tego odwołać tak:
Context globalJndi = new new InitialContext();
cośtam = globalJndi.lookup("java:comp/env/xyz");
albo
EJBContext ejbContext = .....
cośtam = ejbContext.lookup("xyz");
Tak na marginesie: Context#lookup deklaruje NamingException,
EJBContext#lookup tego nie robi, więc jest przyjemniejszy w użyciu.
> Moja wiedza na temat EJB skończyła się na wersji 2.1. Z tego co mi się
> wydawało to przy definiowaniu EJB podawało się nazwy JNDI interfejsu
> lokalnego i zdalnego(w przypadku gdy chcieliśmy mieć dostęp do EJB po
> local i remote).
> Nazwy te miałyby być zdefiniowane w "globalnym JNDI" i dostęp do beana
> byłby za pomocą lookup("nazwa_JNDI_interfejsu_lokalnego") lub lookup
> ("nazwa_JNDI_interfejsu_zdalengo").
Nie definiowałeś jego miejsca w globalnym JNDI, tylko jego nazwę w
ENC.
Gdybyś miał lokalne bean'y w globalnym JNDI, to byś nie musiał potem
dla każdego innego komponentu, który go potrzebuje, deklarować tego o
czym piszesz poniżej:
> Z 2 strony gdy chcemy odwołac się do danego EJB z innego EJB lub
> servletu/JSP to można zdefiniować w odpowiednich plikach (dla servlet/
> jsp to będzie web.xml a dla EJB to jakis tam ejb-jar.xml) referencje
> do tego EJB za pomocą:
> ejb-ref/ejb-local-ref plus dodatkowo określić (jaka jest nazwa pliku i
> jak wygląda takie określenie zależy od kontenera) jak "globalna nazwa
> JNDI" mapuję się na element występujący w ejb-ref-name/ejb-local-ref-
> name.
> W ten sposób mapuję sobie interfejs zdalny/lokalny beana do "lokalnego
> nazwy JNDI" i odwołuje się za pomocą lookup("java:comp/env/...").
> Z tego co pamiętam w Websphere tak właśnie to działalo...
>
> W takim razie moja zrozumienie nie do końca pasuję do stwierdzenia, że
> lokalne EJB nie rejestrują się w globalnym JNDI ...
No jest tak jak piszesz i tak, jak ja pisałem: jeśli masz lokalny
session bean A i chcesz mieć go dostępnego w "java:comp/env/..."
bean'a B, to musisz go zadeklarować w deskryptorze albo w adnotacjach
dla tego B. Mało tego - rejestracja dokonywana jest podczas
instalowania aplikacji (deployowania) więc nie da się tego dorobić w
"runtime". Nie wiem jak w WebSphere, ale Glassfish nie włoży lokalnego
bean'a do globalnego JNDI, jedyny sposób, żeby się do niego dostać to
przez lokalny kontekst, co wiąże się z tym o czym pisałeś - trzeba go
zadeklarować "u konsumenta".
Jeśli mamy natomiast zdalny session bean, niech się nazywa R z
interfejsem RRemote, to mogę w dowolnym miejscu dowolnej aplikacji
(nieważne czy to jest ten sam EAR, inny EAR, osobny moduł EJB czy
zdalna aplikacja desktop) się do niego dostać beż żadnego
wcześniejszego rejestrowania czegokolwiek, po prostu:
Context ctx = ...zależy od kontenera EJB, np. new InitialContext();
ctx.lookup("lokalizacja_w_globalnym_JNDI");
Na nieszczęście, EJB do wersji 3.0 włącznie nie definiuje domyślnych
nazw i każdy serwer nadaje nazwy jak mu się podoba, przykładowo
Glassfish każdego zdalnego bean'a domyślnie zapakuje do globalnego
JNDI pod nazwą taką, jaka jest pełna nazwa klasy interfejsu zdalnego,
przykładowo:
RRemote rBean = ctx.lookup("pl.pakiecik.RRemote");
rBean.runForrestRunnnnn();
Wracając do lokalnych, jak już mowa o Glassfish'u - w sprawie nazw
beanów stosuje domyślnie nazwę klasy bez pakietu.
Taki mały przykład:
@Local
public interface DbUpdateExec {
void update(DbUpdateCmd updateCommand);
}
@Stateless
public class ContractSubjectUpdateBean implements DbUpdateExec {
...
}
@Stateless
@EJBs({
@EJB(name="generic", beanName="GenericUpdateExecBean",
beanInterface=DbUpdateExec.class),
@EJB(name="contractSubject", beanName="ContractSubjectUpdateBean",
beanInterface=DbUpdateExec.class)
// more to come //
})
public class DbUpdateServiceBean implements DbUpdateServiceRemote {
@Resource
private SessionContext ctx;
@Override
public void update(Iterable<DbUpdateCmd> cmds) {
for (DbUpdateCmd cmd : cmds) {
String execName = cmd.getExecName();
DbUpdateExec exec = (DbUpdateExec) ctx.lookup(execName);
exec.update(cmd);
}
}
}
Zauważ, że DbUpdateExec jest lokalnym interfejsem. Z tego właśnie
powodu, dla DbUpdateServiceBean muszę robić tą cholerną deklaracje
wszystkich beanów które go implementują. Jak widać "beanName" to nazwa
samej klasy bean'a, "name" to nazwa pod którą chcę go mieć w moim
lokalnym jndi no i interfejs... wiadomo.
>
> @Kornel:
> Spring w przestrzeni nazw jee ma dedykowany element do odwolywania sie
> do stateless EJB: local-slsb i remote-slsb.
Zastanawia mnie tylko jak to możliwe, że może on dostarczyć _dowolny_
lokalny session bean na podstawie tylko swojego (Springowego)
kontekstu, skoro kontener EJB nie udostępni lokalnych session beanów
inaczej niż przez ENC...
A może taki Spring dostarczy tylko to, co jest już jest w jakimś ENC
(np. skonfigurowane w web.xml)...
--
Witold Szczerba
miluch
Staram się czaic, ale proszę jeszcze o uściślenie...
On 25 Mar, 11:30, Witold Szczerba <pljosh.m...@gmail.com> wrote:
> On 25 Mar, 09:57, miluch <jmilkiew...@gmail.com> wrote:
>
> > Witam
>
> > Witek a mógłbyś mi napisać co rozumiesz pod nazwą globalne jndi?
>
> Chodzi mi o globalny kontekst, dostępny przez interfejs
> javax.naming.Context, w przeciwieństwie do jego gałęzi java:comp/env/*
> lub po prostu EJBContext (SessionContext dla SFSB/SLSB czy
> MessageDrivenContext dla MDB), który jest kontekstem danego bean'a:
Nie do końca rozumiem to zdanie.
Czy chodzi o to, że jako global context rozumiesz nie gałąź java:comp/
env/* ani nie obiekt EJBContext ?
>
> The EJBContext interface provides an instance with access to the
> container-provided runtime context of an enterprise Bean instance.
>
> Tzn. jeśli mamy w ENC danego bean'a dostępne coś pod nazwą: xyz to
> możemy się do tego odwołać tak:
> Context globalJndi = new new InitialContext();
> cośtam = globalJndi.lookup("java:comp/env/xyz");
> albo
> EJBContext ejbContext = .....
> cośtam = ejbContext.lookup("xyz");
>
Co to znaczy dostępne coś dla danego beana?Chodzi o to, że ENC będzie
zawierać wszystkie obiekty, do których zostały utworzone
referencje ,czyli dla danego EJB zostały zdefiniowane: ejb-ref,
resource-ref,env-entry?
> Tak na marginesie: Context#lookup deklaruje NamingException,
> EJBContext#lookup tego nie robi, więc jest przyjemniejszy w użyciu.
>
> > Moja wiedza na temat EJB skończyła się na wersji 2.1. Z tego co mi się
> > wydawało to przy definiowaniu EJB podawało się nazwy JNDI interfejsu
> > lokalnego i zdalnego(w przypadku gdy chcieliśmy mieć dostęp do EJB po
> > local i remote).
> > Nazwy te miałyby być zdefiniowane w "globalnym JNDI" i dostęp do beana
> > byłby za pomocą lookup("nazwa_JNDI_interfejsu_lokalnego") lub lookup
> > ("nazwa_JNDI_interfejsu_zdalengo").
>
> Nie definiowałeś jego miejsca w globalnym JNDI, tylko jego nazwę w
> ENC.
Tego właśnie nie czaję. Czemu w ENC a nie w w global JNDI?
W Websphere definiując sesyjne EJB 2.1, o dostępie zdalnym i lokalnym,
zostaną stworzone 2 wpisy do JNDI - jeden dla interfejsu zdalnego oraz
2 dla interfejsu lokalnego. Websphere domyślnie są to pełne nazwy
pakietowe interfejsów zdalnego i lokalnego.
I teraz aby odwołac się do tych beanów to przykładowo w servlecie
robie:
dla zdalnego:
Contex ctx = new IntitialContext();
ctx.lookup("pelna_nazwa_pakietowa_interfejsu_remote")
a jak chce lokalny to:
Contex ctx = new IntitialContext();
ctx.lookup("pelna_nazwa_pakietowa_interfejsu_local")
czyli jak dla mnie odwołuję się do globalnego JNDI, nie zależnie czy
chce dostac referencje do local czy remote...
Wracając co twojej odpowiedzi:
> Nie definiowałeś jego miejsca w globalnym JNDI, tylko jego nazwę w
> ENC.
Nie mogę wyobrazić sobie czemu w ENC,skoro jak dla mnie ENC jest per
Bean, czyli (sorry znowu EJB 2.1) to co wrzucę do ejb-ref, resource-
ref składa się na ENC.
Chyba, że chodzi o to że zdefiniowanie beana o dostępie lokalym -
automagicznie "wpycha" go do ENC innych beanów...
> Gdybyś miał lokalne bean'y w globalnym JNDI, to byś nie musiał potem
> dla każdego innego komponentu, który go potrzebuje, deklarować tego o
> czym piszesz poniżej:
Sorry ale z tego co pamiętam to właśnie tak to robiliśmy...
Nie do końca pamiętam, jak to było robione gdy EJB chciał innego EJB,
ale jak servlet chciał lokalnego EJB to na 100 %
definiowaliśmy ejb-local-ref...
>
> > Z 2 strony gdy chcemy odwołac się do danego EJB z innego EJB lub
> > servletu/JSP to można zdefiniować w odpowiednich plikach (dla servlet/
> > jsp to będzie web.xml a dla EJB to jakis tam ejb-jar.xml) referencje
> > do tego EJB za pomocą:
> > ejb-ref/ejb-local-ref plus dodatkowo określić (jaka jest nazwa pliku i
> > jak wygląda takie określenie zależy od kontenera) jak "globalna nazwa
> > JNDI" mapuję się na element występujący w ejb-ref-name/ejb-local-ref-
> > name.
> > W ten sposób mapuję sobie interfejs zdalny/lokalny beana do "lokalnego
> > nazwy JNDI" i odwołuje się za pomocą lookup("java:comp/env/...").
> > Z tego co pamiętam w Websphere tak właśnie to działalo...
>
> > W takim razie moja zrozumienie nie do końca pasuję do stwierdzenia, że
> > lokalne EJB nie rejestrują się w globalnym JNDI ...
>
> No jest tak jak piszesz i tak, jak ja pisałem: jeśli masz lokalny
> session bean A i chcesz mieć go dostępnego w "java:comp/env/..."
> bean'a B, to musisz go zadeklarować w deskryptorze albo w adnotacjach
> dla tego B.
Na podstawie tego FAQ glassfishowego rozumiem, że chodzi o
zdefiniowanie ejb-local-ref lub odpowiednich atrybutów dla annotacji
@EJB
> Mało tego - rejestracja dokonywana jest podczas instalowania aplikacji (deployowania) więc nie da się tego dorobić w
> "runtime". Nie wiem jak w WebSphere, ale Glassfish nie włoży lokalnego
> bean'a do globalnego JNDI, jedyny sposób, żeby się do niego dostać to
> przez lokalny kontekst, co wiąże się z tym o czym pisałeś - trzeba go
> zadeklarować "u konsumenta".
Z tego co pamiętam to z poziomu servletu mogę odwołac sie do lokalnego
EJB za pomocą lookup do ENC (java:comp/env/) lub bezpośrednio : lookup
("pelna_pakietowa_nazwa_interfejsu_local");
implementują ? ,,, a nie oznacza to, że DbUpdateServiceBean chce
miec dostęp do beanów :GenericUpdateExecBean oraz
ContractSubjectUpdateBean.
Czyli parametrami wejściowymi bedą : "generic" oraz
"contractSubject" ?
> Jak widać "beanName" to nazwa samej klasy bean'a, "name" to nazwa pod którą chcę go mieć w moim
> lokalnym jndi no i interfejs... wiadomo.
>
>
>
> > @Kornel:
> > Spring w przestrzeni nazw jee ma dedykowany element do odwolywania sie
> > do stateless EJB: local-slsb i remote-slsb.
>
> Zastanawia mnie tylko jak to możliwe, że może on dostarczyć _dowolny_
> lokalny session bean na podstawie tylko swojego (Springowego)
> kontekstu, skoro kontener EJB nie udostępni lokalnych session beanów
> inaczej niż przez ENC...
> A może taki Spring dostarczy tylko to, co jest już jest w jakimś ENC
> (np. skonfigurowane w web.xml)...
>
Dokładnie... Spring nic sam z siebie nie zrobi... Ma możliwośc tylko
sięgnięcia do contextu. Oczywiście oprócz podania nazwy JNDI pod która
siedzi EJB dodatkowo możesz ustawic flagę: resource-ref, która mówi
czy to lookup ma byc po wskazanej przez ciebie nazwie JNDI czy też
prefixowac ta nazwe przy pomocy java:comp/env/
> --
> Witold Szczerba
pzdr miluch
Witold Szczerba
> On 25 Mar, 11:30, Witold Szczerba <pljosh.m...@gmail.com> wrote:
> > Chodzi mi o globalny kontekst, dostępny przez interfejs
> > javax.naming.Context, w przeciwieństwie do jego gałęzi java:comp/env/*
> > lub po prostu EJBContext (SessionContext dla SFSB/SLSB czy
> > MessageDrivenContext dla MDB), który jest kontekstem danego bean'a:
>
> Nie do końca rozumiem to zdanie.
> Czy chodzi o to, że jako global context rozumiesz nie gałąź java:comp/
> env/* ani nie obiekt EJBContext ?
Faktycznie, zamotałem. Początkowo napisałem coś innego, w efekcie
refaktoringu :) wyszło jak widać.
Chodzi mi o to, że pod pojęciem lokalnego kontekstu rozumiem wszystko
to, co znajduje się w gałęzi: java:comp/env/* obiektu InitialContext.
Przy okazji to jest to samo, co znajduje się w głównej gałęzi
EJBContext.
Odnośnie lokalnych SB: jeśli mam moduł EJB, który zawiera lokalnego
session bean'a i taki moduł zainstaluje na serwerze aplikacyjnym, to
jak przeglądam potem globalny JNDI tego serwera to nigdzie takiego
lokalnego SB nie znajduję.
Jeśli mam teraz inny komponent, który chce mieć dostęp do tego
lokalnego SB, to ten komponent musi sobie w swoim ENC go zadeklarować
(albo przez deskryptor XML, albo korzystając z adnotacji dostępnych w
EJB3). Jeśli tego nie zrobi, to ctx.lookup nie znajdzie lokalnego SB.
Tak przynajmniej jest w Glassfish'u wg moich obserwacji.
Nie rozumiem więc tego, co pisałeś wcześniej, że WebSphere udostępnia
w globalnym JNDI nie tylko zdalne, ale też lokalne SB. Skoro tak jest,
to po co w web.xml deklarować i umieszczać w java:comp/env taką
referencję, skoro można ją pobrać bezpośrednio z InitialContext?
> Z tego co pamiętam to z poziomu servletu mogę odwołac sie do lokalnego
> EJB za pomocą lookup do ENC (java:comp/env/) lub bezpośrednio : lookup
> ("pelna_pakietowa_nazwa_interfejsu_local");
No właśnie, skoro można się odwołać tak:
globalCtx. lookup("pelna_pakietowa_nazwa_interfejsu_local");
To po co w ogóle zawracać sobie głowę deklarowaniem lokalnych SB w
takim web.xml, skoro i tak można bez tego pobrać te komponenty po
prostu z InitialContext?
> > Zauważ, że DbUpdateExec jest lokalnym interfejsem. Z tego właśnie
> > powodu, dla DbUpdateServiceBean muszę robić tą cholerną deklaracje
> > wszystkich beanów które go implementują.
>
> implementują ? ,,, a nie oznacza to, że DbUpdateServiceBean chce
> miec dostęp do beanów :GenericUpdateExecBean oraz
> ContractSubjectUpdateBean.
> Czyli parametrami wejściowymi bedą : "generic" oraz
> "contractSubject" ?
Tak, chociaż jakbym mógł to bym wywalił te głupie mapowanie z
adnotacji @EJBs dla klasy DbUpdateServiceBean. Ono mi tam tylko
przeszkadza, jednak bez niego nie jestem w stanie w żaden sposób
dostać referencji do tych lokalnych SB.
> Dokładnie... Spring nic sam z siebie nie zrobi... Ma możliwośc tylko
> sięgnięcia do contextu. Oczywiście oprócz podania nazwy JNDI pod która
> siedzi EJB dodatkowo możesz ustawic flagę: resource-ref, która mówi
> czy to lookup ma byc po wskazanej przez ciebie nazwie JNDI czy też
> prefixowac ta nazwe przy pomocy java:comp/env/
No właśnie tu jest moja konsternacja: do jakiego kontekstu może Spring
sięgnąć? Jeśli do korzenia w InitialContext - wtedy nie będzie w
stanie pobrać tych lokalnych SB (tutaj opieram się na swoim
doświadczeniu z Glassfish'em). Jeśli natomiast do lokalnego kontekstu
takiego np. web.xml - to znaczy, że wszystko co chcemy zadeklarować w
Springu to musimy wcześniej jeszcze raz w web.xml zrobić (a w
przypadku SB w EJB2.x - to jeszcze w ejb.xml) - czyli każdy komponent
po dwa (trzy w EJB2) razy deklarować w dwóch (trzech) różnych
deskryptorach :/ Jak to mówią: "to jest jakaś masakra".