Comment l'EJB client de localiser le serveur EJB sans url?

Il y a deux choses qui sont à faire ici.

La première chose, c'est que la façon dont pour obtenir une référence à une distance d'EJB n'est pas spécifié dans Java EE. Vous êtes à la merci de la façon dont un individu vendeur pense qu'il devrait être fait.

Bien que JNDI est la norme de facto utilisé pour cela, même ce qui, en soi n'est pas obligatoire.

Exemple: JBoss jusqu'à AS7

Dans JBoss as jusqu'à 7, la séquence suivante a été utilisée pour obtenir une référence à distance:

Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
env.put(Context.PROVIDER_URL, "jnp://myserver.example.com:1099");
InitialContext context = new InitialContext(env);

Bean bean = (Bean) context.lookup("myear/MyBean/remote");

Ici, l'URL du serveur distant est prévue pour le contexte initial et à partir de ce contexte d'un bean est extrait. (Notez que vous devez PAS ajouter le bien connu "java:/" préfixe ici, ou sinon, il sera intercepté par JNDI et résolu localement, malgré le fait que la recherche sur une distance de contexte)

Puisque cette méthode a été tel que mentionné est pas normalisé, un seul fournisseur peut changer complètement entre les versions de mises en œuvre. Même pour les implémentations de la même version Java EE.

Exemple: JBoss AS7

Dans JBoss as 7, JBoss voulais partir JNDI (parce qu'il n'a pas été spécifié que JNDI devait être utilisé) et maintenant il arrive dans environ la façon suivante:

Vous aurez d'abord besoin de mettre un jboss-ejb-client.properties fichier sur votre chemin de classe avec le contexte suivant:

endpoint.name = client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED = false
remote.connections = default
remote.connection.default.host = myserver.example.com
remote.connection.default.port = 4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS = false

Et utiliser le code comme le suivant:

Properties env = new Properties();
env.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(env);

Bean bean = (Bean) context.lookup("ejb:/myear/mymodule/MyBean!com.example.Bean");

Donc, à partir du code, il ne ressemble à aucune URL n'est pas précisée, mais il est statiquement caché dans un fichier de config.

---

Client De L'Application Conteneur

Aujourd'hui, j'ai trouvé un autre exemple où Netbeans 7, Java EE 6 et GlassFish 3 sont utilisés. Le côté client de code [...]

C'est encore une autre chose. Ce qui est démontré il y a une soi-disant Client de l'Application Conteneur (aka ACC).

Ce qui est différent de l'exemple ci-dessus, où un Java SE application utilisée JNDI pour communiquer avec le serveur distant. Le Client de l'Application Conteneur est un peu d'une obscure chose en Java EE. L'idée semble être que vous téléchargez le client de code dynamique à partir du Serveur (par exemple, une Applet ou Java Web Start app), et qu'il puis comme par magie "sait" où elle provient. Il y a très peu de soutien pour (statique) d'injection dans la classe principale, que vous pouvez utiliser pour injecter à distance haricots directement.

Le Client de l'Application Conteneur est une idée à partir des premiers jours de Java EE et autant que je sache, n'a jamais eu beaucoup d'attention. Après toutes ces années, il n'a jamais avancé beaucoup après sa conception initiale. Puisqu'il nécessite toujours une tonne de fournisseur de choses à faire, je pense que la plupart des gens ne vous embêtez pas avec et il suffit d'utiliser JNDI.

OriginalL'auteur Arjan Tijms