Injecter des EJBs distant dans une application CDI

--0016e68ee210b8b56f04af421d0f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Salut,
je suis en train de d=E9velopper une application dans laquelle je voudrais
utilsier de l'injection de d=E9pendance "normalis=E9e" donc avec CDI.
Le c=F4t=E9 fun, c'est que cette application comporte une partie serveur
s'ex=E9cutant dans un EAR d=E9ploy=E9 sur Glassfish. Mais aussi sur un clie=
nt
Glassfish.
Dans ce second contexte, on ne dispose pas "n standard", de l'injection des
d=E9pendances.
J'ai donc ajout=E9 Weld 1.0.1 =E0 mon CLASSPATH, et roulez jeunesse ! J'ai =
pu
faire de l'injection de beans dans mon client.
Seulement, je ne peux pas injecter d'EJBs du serveur dans les classes de mo=
n
client. P=E9nible quoi.
J'ai donc envisag=E9 une premi=E8re solution reposant sur une extension CDI=
 Weld
qui, une fois les classes "classiques" charg=E9es, liste les EJBs distants =
(=E0
grands coups de Context.listBindings), r=E9cup=E8re leurs classes, et se ch=
arge
d'instancier les interfaces idoines. Ca paraissait g=E9nial, sauf qu'il sem=
ble
que Glassfish soit "un peu" bugg=E9 (voir par exemple ici :
http://java.net/jira/browse/GLASSFISH-17219).
Du coup, comme il n'est plus possible de tout faire au d=E9marrage, je me
r=E9soud =E0 faire les choses au fur et =E0 mesure.
Et pour =E7a, j'ai l'impression de me lancer dans une mauvaise id=E9e : je =
vais
=E9crire une sous-classe de javax.enterprise.inject.Instance qui, =E0 l'app=
el du
"select" va faire un lookup JNDI du nom de l'interface pour ensuite, au
moment du get(), r=E9cup=E9rer une instance de mon EJB pour appeler des m=
=E9thodes
dessus.
Ca vous para=EEt cens=E9 ? Voire ... intelligent ? Ou c'est compl=E8teemnt =
idiot
et il y a d=E9ja une fa=E7on subtile de faire =E7a ?

--=20
Nicolas Delsaux

--0016e68ee210b8b56f04af421d0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Salut,<br clear=3D"all"></div><div>je suis en train de d=E9velopper un=
e application dans laquelle je voudrais utilsier de l&#39;injection de d=E9=
pendance &quot;normalis=E9e&quot; donc avec CDI.</div><div>Le c=F4t=E9 fun,=
 c&#39;est que cette application comporte une partie serveur s&#39;ex=E9cut=
ant dans un EAR d=E9ploy=E9 sur Glassfish. Mais aussi sur un client Glassfi=
sh.</div>
<div>Dans ce second contexte, on ne dispose pas &quot;n standard&quot;, de =
l&#39;injection des d=E9pendances.</div><div>J&#39;ai donc ajout=E9 Weld 1.=
0.1 =E0 mon CLASSPATH, et roulez jeunesse ! J&#39;ai pu faire de l&#39;inje=
ction de beans dans mon client.</div>
<div>Seulement, je ne peux pas injecter d&#39;EJBs du serveur dans les clas=
ses de mon client. P=E9nible quoi.</div><div>J&#39;ai donc envisag=E9 une p=
remi=E8re solution reposant sur une extension CDI Weld qui, une fois les cl=
asses &quot;classiques&quot; charg=E9es, liste les EJBs distants (=E0 grand=
s coups de Context.listBindings), r=E9cup=E8re leurs classes, et se charge =
d&#39;instancier les interfaces idoines. Ca paraissait g=E9nial, sauf qu&#3=
9;il semble que Glassfish soit &quot;un peu&quot; bugg=E9 (voir par exemple=
 ici : <a href=3D"http://java.net/jira/browse/GLASSFISH-17219">http://java.=
net/jira/browse/GLASSFISH-17219</a>).</div>
<div>Du coup, comme il n&#39;est plus possible de tout faire au d=E9marrage=
, je me r=E9soud =E0 faire les choses au fur et =E0 mesure.</div><div>Et po=
ur =E7a, j&#39;ai l&#39;impression de me lancer dans une mauvaise id=E9e : =
je vais =E9crire une sous-classe de javax.enterprise.inject.Instance qui, =
=E0 l&#39;appel du &quot;select&quot; va faire un lookup JNDI du nom de l&#=
39;interface pour ensuite, au moment du get(), r=E9cup=E9rer une instance d=
e mon EJB pour appeler des m=E9thodes dessus.</div>
<div>Ca vous para=EEt cens=E9 ? Voire ... intelligent ? Ou c&#39;est compl=
=E8teemnt idiot et il y a d=E9ja une fa=E7on subtile de faire =E7a ?</div><=
br>-- <br>Nicolas Delsaux<br><br>

--0016e68ee210b8b56f04af421d0f--