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
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:
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
Maintenant, créez un autre projet de guerre
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.