Echec de la recherche ejb avec NamingException

J’ai ajouté ce qui suit dans mon web.xml:

 ejb/userManagerBean Session gha.ywk.name.entry.ejb.usermanager.UserManagerHome what should go here??  

Le code Java suivant me donne NamingException:

 public UserManager getUserManager () throws HUDException { Ssortingng ROLE_JNDI_NAME = "ejb/userManagerBean"; try { Properties props = System.getProperties(); Context ctx = new InitialContext(props); UserManagerHome userHome = (UserManagerHome) ctx.lookup(ROLE_JNDI_NAME); UserManager userManager = userHome.create(); WASSSecurity user = userManager.getUserProfile("user101", null); return userManager; } catch (NamingException e) { log.error("Error Occured while getting EJB UserManager" + e); return null; } catch (RemoteException ex) { log.error("Error Occured while getting EJB UserManager" + ex); return null; } catch (CreateException ex) { log.error("Error Occured while getting EJB UserManager" + ex); return null; } } 

Le code est utilisé à l’intérieur du conteneur. J’entends par là que le .WAR est déployé sur le serveur (Sun Application Server).

StackTrace (après la suggestion de jsight):

 >Exception occurred in target VM: com.sun.enterprise.naming.java.javaURLContext.(Ljava/util/Hashtable;Lcom/sun/enterprise/naming/NamingManagerImpl;)V java.lang.NoSuchMethodError: com.sun.enterprise.naming.java.javaURLContext.(Ljava/util/Hashtable;Lcom/sun/enterprise/naming/NamingManagerImpl;)V at com.sun.enterprise.naming.java.javaURLContextFactory.getObjectInstance(javaURLContextFactory.java:32) at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:584) at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:533) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:279) at javax.naming.InitialContext.lookup(InitialContext.java:351) at gov.hud.pih.eiv.web.EjbClient.EjbClient.getUserManager(EjbClient.java:34) 

Je pense que vous souhaitez accéder à une application EJB (appelée module EJB) à partir d’une application Web de Sun Application Server, n’est-ce pas?

OK allons-y.

Lorsque vous déployez un EJB sur un serveur d’applications, celui-ci lui atsortingbue une adresse, appelée adresse JNDI globale, qui permet d’y accéder (par exemple, votre adresse). Cela change d’un serveur d’applications à un autre.

Dans JBoss Application Server, vous pouvez voir l’adresse JNDI globale (après le démarrage) à l’adresse suivante

 http://127.0.0.1:8080/jmx-console/HtmlAdaptor 

Dans Sun Application Server, si vous souhaitez voir l’adresse JNDI globale (après le démarrage), procédez comme suit:

Accédez à la console d’administration à l’adresse suivante

 http://127.0.0.1:4848/asadmin 

Et cliquez sur JNDI pour naviguer

Si votre EJB N’EST PAS enregistré sur place, il y a un problème

EJB est disponible en deux versions: EJB 2.1 et EJB 3.0. Alors, quelle est la difference ?

Bien bien bien…

Commençons par EJB 2.1

  1. Créer une interface d’accueil

Il définit des méthodes pour CRÉER, détruire et rechercher des objects EJB locaux ou distants. Il agit comme une interface de cycle de vie pour les objects EJB. Toutes les interfaces d’accueil doivent étendre l’interface standard javax.ejb.EJBHome – si vous utilisez un object ejb distant – ou javax.ejb.EJBLocalHome – si vous utilisez un object EJB local.

 // a remote EJB object - extends javax.ejb.EJBHome // a local EJB object - extends javax.ejb.EJBLocalHome public interface MyBeanRemoteHome extends javax.ejb.EJBHome { MyBeanRemote create() throws javax.ejb.CreateException, java.rmi.RemoteException; } 

Application Server créera des objects Home afin d’obtenir un object EJB, rien d’autre.

Prenez soin de ce qui suit

L’interface de la maison distante d’un bean session DOIT DEFINIR UNE OU PLUSIEURS méthodes create . Un bean session sans état DOIT DÉFINIR exactement une méthode sans argument.

La clause throws DOIT INCLURE Javax.ejb.CreateException

Si votre interface Home s’étend à javax.ejb.EJBHome, les clauses throws DOIVENT INCLUER l’exception java.rmi.RemoteException. S’il étend javax.ejb.EJBLocalHome, NE DOIT PAS INCLUER l’exception java.rmi.RemoteException.

Chaque méthode de création d’un bean de session avec état DOIT ÊTRE NOMMÉE create , et elle doit correspondre à l’une des méthodes Init ou l’une des méthodes ejbCreate définies dans la classe de bean de session. La méthode correspondante ejbCreate DOIT AVOIR LE MÊME NUMÉRO ET LES TYPES D’ARGUMENTS. La méthode create pour un bean de session sans état DOIT ÊTRE NOMMÉE. Create mais ne doit pas nécessairement avoir une méthode «ejbCreate» correspondante.


Créez maintenant une interface métier afin de définir la logique métier dans notre object EJB.

 // a remote EJB object - extends javax.ejb.EJBObject // a local EJB object - extends javax.ejb.EJBLocalObject public interface MyBeanRemote extends javax.ejb.EJBObject { void doSomething() throws java.rmi.RemoteException; } 

Maintenant, prenez soin de ce qui suit

Si vous utilisez un object EJB distant, les méthodes d’interface distante NE DOIVENT PAS EXPOSER les types d’interface locale ou les types d’interface home locale.

Si votre interface Home s’étend à javax.ejb.EJBObject, les clauses throws DOIVENT INCLUER l’exception java.rmi.RemoteException. S’il étend javax.ejb.EJBLocalObject, NE DOIT PAS INCLUER l’exception java.rmi.RemoteException.


Maintenant notre EJB

 public class MyBean implements javax.ejb.SessionBean { // why create method ? Take a special look at EJB Home details (above) public void create() { System.out.println("create"); } public void doSomething() throws java.rmi.RemoteException { // some code }; } 

Maintenant, prenez soin de ce qui suit

Il DOIT IMPLÉMENTER javax.ejb.SessionBean. Il définit quatre méthodes – non présentées ci-dessus: setSessionContext, ejbRemove, ejbPassivate et ejbActivate.

Notez que notre bean n’implémente pas notre interface métier car la spécification EJB indique:

Pour chaque méthode définie dans l’interface, il doit exister une méthode correspondante dans la classe du bean de session. La méthode correspondante doit avoir:

  • Le même nom
  • Le même nombre et le même type d’arguments, et le même type de retour.
  • Toutes les exceptions définies dans la clause throws de la méthode correspondante de la classe de bean session doivent être définies dans la clause throws de la méthode de l’interface locale.

Et VOUS DEVEZ DÉCLARER un fichier ejb-jar.xml selon

     HelloWorldEJB br.com.MyBeanRemoteHome br.com.MyBeanRemote br.com.MyBeanLocalHome br.com.MyBeanLocal br.com.MyBean Stateless Container    

Si vous n’avez pas d’object EJB local, supprimez-le du descripteur de déploiement ci-dessus.

 br.com.MyBeanLocalHome br.com.MyBeanLocal 

Si vous n’avez pas d’object EJB distant, supprimez-le du descripteur de déploiement ci-dessus.

 br.com.MyBeanRemoteHome br.com.MyBeanRemote 

Et mettre dans le répertoire META-INF

Notre fichier jar contiendra le suivant

 /META-INF/ejb-jar.xml br.com.MyBean.class br.com.MyBeanRemote.class br.com.MyBeanRemoteHome.class 

Maintenant notre EJB 3.0

 // or @Local // You can not put @Remote and @Local at the same time @Remote public interface MyBean { void doSomething(); } @Stateless public class MyBeanStateless implements MyBean { public void doSomething() { } } 

Rien d’autre,

Dans JBoss, mettez le fichier jar dans

 /server/default/deploy 

Dans la console d’administration de Sun Application Server (après le démarrage)

 http://127.0.0.1:4848/asadmin 

Et accédez aux modules EJB afin de déployer votre fichier ejb-jar

Comme vous avez des problèmes lors du déploiement de votre application dans NetBeans, je suggère ce qui suit

  1. Créer une simple bibliothèque Java PROJECT (un simple jar sans méthode principale)
  2. Ajoutez / server / default / lib (contient les fichiers jar afin de pouvoir récupérer les fichiers jar de votre EJB) dans votre application Java, que vous utilisiez JBoss (je ne sais pas quel répertoire dans Sun Application Server)
  3. Implémenter le code ci-dessus

Maintenant, créez un autre projet de guerre

  1. Ajoutez notre projet créé ci-dessus et ajoutez / client (contient les fichiers jar afin d’accéder à nos EJB). Encore une fois, je ne sais pas quel répertoire dans Sun Application Server. Ckeck sa documentation.
  2. Voir son adresse de mappage globale comme indiqué en haut de la réponse

Et implémentez le code suivant dans votre Servlet ou autre chose si vous utilisez JBoss

 public static Context getInitialContext() throws javax.naming.NamingException { Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); p.put(Context.URL_PKG_PREFIXES, " org.jboss.naming:org.jnp.interfaces"); p.put(Context.PROVIDER_URL, "jnp://127.0.0.1:1099"); return new javax.naming.InitialContext(p); } 

Ou le suivant si vous utilisez Sun Application Server – mettez le fichier appserv-rt.jar (je ne sais pas quel passé contient appserv-rt.jar dans Sun Application Server) dans votre chemin d’access aux classes

 public static Context getInitialContext() throws javax.naming.NamingException { return new javax.naming.InitialContext(); } 

Pour accéder à votre EJB dans notre Servlet ou autre chose

 MyBeanRemote myBean = (MyBeanRemote) getInitialContext().lookup(); myBean.doSomething(); 

Cordialement,

Peut-être que la chaîne de recherche devrait en réalité être: “java: comp / env / ejb / userManagerBean”?

Les deux dernières réponses sont correctes en ce sens qu’il s’agit de choses que vous devez changer / réparer. Mais la NoSuchMethodError que vous voyez ne provient pas de votre code, ni d’éléments tentant de trouver votre code (produirait une sorte de NoClassDefFoundException, je pense, si c’était le cas). Cela ressemble davantage à des versions incompatibles du fournisseur JNDI fourni par le conteneur et aux souhaits de l’implémentation JNDI dans la bibliothèque Java. C’est une réponse assez vague, mais, imaginons qu’il soit possible de résoudre ce problème en mettant à niveau votre serveur d’applications et en s’assurant que vous ne déployez pas de copies éventuellement obsolètes de classes d’infrastructure liées à JNDI avec votre application, cela pourrait interférer.

Commencez par réparer votre fichier web.xml et ajoutez-y l’interface à distance:

  Sample EJB SampleBean Session com.SampleHome com.Sample   

Ensuite, en ce qui concerne java.lang.NoSuchMethodError , Sean a raison, il existe une différence entre la version de la “bibliothèque client” du serveur d’applications que vous utilisez dans NetBeans et la version du serveur d’applications (côté serveur). Cependant, je ne peux pas vous dire exactement quels JAR vous devez aligner, reportez-vous à la documentation de Sun Application Server.

PS: Ce n’est pas une réponse directe au problème, mais je ne pense pas que vous transmettez actuellement des propriétés utiles lors de la création de votre contexte initial avec les résultats de l’appel à System.getProperties() . Ces propriétés ne sont pas utiles. définir l’environnement d’un contexte (par exemple, la fabrique de contexte initiale). Reportez-vous aux javadocs InitialContext pour plus de détails.