Liaisons JNDI de JBoss AS 7.1.1

Question

Lorsque je déploie une EJB3 haricot avec la norme @Stateless , @Remote annotations à mon JBoss AS 7.1.1 Je constate ce qui suit JNDI sur la sortie de la console du serveur :

22:31:43,209 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor]    
(MSC service thread 1-2) JNDI bindings for session bean named HelloEJB3Bean
 in deployment unit deployment "hello.jar" are as follows:

    java:global/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:app/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:module/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:jboss/exported/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:global/hello/HelloEJB3Bean
    java:app/hello/HelloEJB3Bean
    java:module/HelloEJB3Bean

Cependant, je trouve ensuite et appelle le bean à partir d'une classe Java autonome (en utilisant un code adapté de les tutoriels de démarrage rapide de JBoss AS 7.1.1 ) en utilisant un JNDI Chaîne du type suivant :

String jndiName = "ejb:" + appName + "/"      + moduleName + "/" + distinctName
                         + "/"     + beanName + "!" + viewClassName
                         + (stateful?"?stateful":"");

(qui n'appartient pas à l'un des espaces de noms/liaisons ci-dessus).

1. Pourquoi y a-t-il autant de liaisons JNDI et quelle différence cela fait-il si j'utilise l'une ou l'autre ?
2. Existe-t-il une manière standard de procéder, par exemple en utilisant la fonction ejb:/ (puisque c'est ce qui apparaît dans le tutoriel de démarrage rapide donné ci-dessus).
3. Pourquoi le ejb:/ (qui existe manifestement puisque c'est ce que j'ai utilisé pour parler à mon haricot) N'EST PAS signalé dans la sortie de JBoss AS 7.1.1 ?

Answer 1

1) Ces éléments sont tous spécifiés dans le Spécification Java EE (jetez un coup d'œil au capter EE.5.2.2), mais il suffit de dire que ce sont des "espaces de noms" et, selon "comment" et "d'où" vous accédez à ces EJB, vous finirez par l'obtenir en fonction de chacune de ces entrées. Par exemple, si un code du même module (EAR) demande un EJB, il sera probablement acheminé par le module java:module. Les différences résident principalement dans le degré d'optimisation de l'appel, car un accès "comp" nécessitera moins de travail "en coulisse" qu'un accès "global".

2) La spécification EE dit :

Cette spécification recommande, mais n'exige pas, que les références aux beans d'entreprise soient organisées dans le sous-contexte ejb de l'environnement du composant d'application (dans l'environnement java:compendium). (c'est-à-dire dans le contexte JNDI java:comp/env/ejb). Notez que les références aux beans d'entreprise déclarés via des annotations ne seront pas, par défaut, dans aucun sous-contexte.

3) Je n'ai pas de réponse à cela, mais peut-être que quelqu'un à #jboss (ou #jboss-ejb3) sur freenode peut répondre :-)

Answer 2

ejb:/ est l'espace de nom propriétaire utilisé par JBoss pour à distance clients.

Introduite dans JBoss AS 7.x, elle remplace la méthode standard de facto de JNDI à distance, qui consiste à utiliser le même espace de noms JNDI que celui utilisé localement, mais à fournir au contexte initial les propriétés qui spécifient l'emplacement du serveur distant.

La raison pour laquelle ejb:/ pour exister est double. Selon JBoss, la méthode de facto d'accès distant à JNDI n'est pas spécifiée dans la spécification Java EE et il n'y a donc aucune raison d'y adhérer. L'un des objectifs de JBoss AS 7 était d'étudier différentes façons de faire les choses, et en raison des trous dans les spécifications, les EJB distants n'offraient tout simplement aucune opportunité.

Avec le ejb:/ il est censé être plus facile pour le "pilote" distant d'intercepter les demandes de haricots EJB distants et, dans le même temps, il s'assure que seuls les haricots EJB peuvent être demandés, et non les files d'attente JMS (pour lesquelles il n'est pas non plus précisé comment les obtenir à distance) et, pire encore, les sources de données.