Injecter des EJBs distant dans une application CDI

[Nicolas Delsaux]

Salut,
je suis en train de développer une application dans laquelle je voudrais
utilsier de l'injection de dépendance "normalisée" donc avec CDI.
Le côté fun, c'est que cette application comporte une partie serveur
s'exécutant dans un EAR déployé sur Glassfish. Mais aussi sur un client
Glassfish.
Dans ce second contexte, on ne dispose pas "n standard", de l'injection des
dépendances.
J'ai donc ajouté Weld 1.0.1 à 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 mon
client. Pénible quoi.
J'ai donc envisagé une première solution reposant sur une extension CDI Weld
qui, une fois les classes "classiques" chargées, liste les EJBs distants (à
grands coups de Context.listBindings), récupère leurs classes, et se charge
d'instancier les interfaces idoines. Ca paraissait génial, sauf qu'il semble
que Glassfish soit "un peu" buggé (voir par exemple ici :
http://java.net/jira/browse/GLASSFISH-17219).
Du coup, comme il n'est plus possible de tout faire au démarrage, je me
résoud à faire les choses au fur et à mesure.
Et pour ça, j'ai l'impression de me lancer dans une mauvaise idée : je vais
écrire une sous-classe de javax.enterprise.inject.Instance qui, à l'appel du
"select" va faire un lookup JNDI du nom de l'interface pour ensuite, au
moment du get(), récupérer une instance de mon EJB pour appeler des méthodes
dessus.
Ca vous paraît censé ? Voire ... intelligent ? Ou c'est complèteemnt idiot
et il y a déja une façon subtile de faire ça ?

[Sebastien Cesbron]

Salut

Je ne connais pas la moitié des technos que tu sites a moitié aussi bien que
je le devrais mais présenté comme tu le présentes ça me parait censé.

Seb

Post by Nicolas Delsaux
Salut,
je suis en train de développer une application dans laquelle je voudrais
utilsier de l'injection de dépendance "normalisée" donc avec CDI.
Le côté fun, c'est que cette application comporte une partie serveur
s'exécutant dans un EAR déployé sur Glassfish. Mais aussi sur un client
Glassfish.
Dans ce second contexte, on ne dispose pas "n standard", de l'injection des
dépendances.
J'ai donc ajouté Weld 1.0.1 à 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
mon client. Pénible quoi.
J'ai donc envisagé une première solution reposant sur une extension CDI
Weld qui, une fois les classes "classiques" chargées, liste les EJBs
distants (à grands coups de Context.listBindings), récupère leurs classes,
et se charge d'instancier les interfaces idoines. Ca paraissait génial, sauf
http://java.net/jira/browse/GLASSFISH-17219).
Du coup, comme il n'est plus possible de tout faire au démarrage, je me
résoud à faire les choses au fur et à mesure.
Et pour ça, j'ai l'impression de me lancer dans une mauvaise idée : je vais
écrire une sous-classe de javax.enterprise.inject.Instance qui, à l'appel du
"select" va faire un lookup JNDI du nom de l'interface pour ensuite, au
moment du get(), récupérer une instance de mon EJB pour appeler des méthodes
dessus.
Ca vous paraît censé ? Voire ... intelligent ? Ou c'est complèteemnt idiot
et il y a déja une façon subtile de faire ça ?
--
Nicolas Delsaux