2008-11-09 8 views
1

Je voudrais appeler un ejb3 lors de l'exécution. Le nom de l'ejb et le nom de la méthode ne seront disponibles qu'au moment de l'exécution, donc je ne peux pas inclure d'interfaces distantes lors de la compilation. Les beans doivent être distribués sur plusieurs serveurs d'applications, et tous les beans doivent être appelés à distance.java ee | ejb3 | envoi d'exécution

Des indices? Plus précisément, je ne pas veulent:

  1. injection de dépendance
  2. inclusion des interfaces EJB spécifiques Appliation dans le répartiteur (ci-dessus)
  3. webservices, thats comme jeter une puissance de traitement pour rien, toutes les conneries xml

Est-il possible de charger une interface distante ejb3 sur le réseau (si oui, comment?), Donc je pourrais mettre en cache l'interface dans quelque hashmap ou quelque chose.

J'ai une solution avec un bean dispatcher distant, que je peux inclure dans le répartiteur principal ci-dessus, qui fait essentiellement la même chose, mais relaie simplement l'appel à un ejb local (que je peux rechercher). . Étant donné le bean dispatcher distant, je peux utiliser l'injection de dépendance.

Merci pour toute aide

(NetBeans et glassfish BTW)

Répondre

1

appels ejb3 utilisent RMI. RMI prend en charge le chargement de classe à distance, donc je suggère d'examiner cela.

également, JMX supporte les invocations à distance entièrement non typées. Donc, si vous pouviez utiliser mbeans au lieu de beans session, cela pourrait fonctionner. (JBoss, par exemple, supporte les mbeans de type ejb3 avec des annotations personnalisées). Enfin, de nombreux serveurs d'applications prennent en charge les appels CORBA et CORBA prend en charge les invocations de méthodes non typées.

0

Vous pouvez utiliser java.rmi.server.RMIClassLoader pour le chargement de classe distant. Vous devrez également charger les classes renvoyées ou renvoyées par le service distant.

0

Cela ne peut pas être fait. Vous aurez toujours une exception "classe non trouvée". C'est à mon avis le plus grand désavantage d'EJB/Java. Vous perdez un peu de dynamcis, car les fonctionnalités de méta-langage sont limitées. EJB3 prend en charge RMI/IIOP, mais pas RMI/JRMP (RMI standard) pour que le chargement dynamique des classes ne soit pas pris en charge. Vous perdez un peu de généralité Java, mais bénéficiez d'autres fonctionnalités telles que la communication sur les transactions et la sécurité.

0

Vous devez utiliser la réflexion pour cela, et c'est très simple à faire. En supposant que vous êtes à la recherche d'une méthode vide appelée meth :

Object ejb = ctx.lookup(bean); 
for (Method m : ejb.getClass().getMethods()) { 
    if (m.getName().equals(meth) && m.getParameterTypes().length == 0) { 
     m.invoke(service); 
    } 
} 

Si vous cherchez une signature de méthode spécifique simplement modifier le critère m.getParameterTypes() en conséquence, par exemplepour une méthode avec un seul paramètre de chaîne, vous pouvez essayer:

Arrays.equals(m.getParameterTypes(), new Class[]{String.class}) 

Et puis passer un tableau de l'objet [] avec les arguments réels au m.invoke() appeler:

m.invoke(service, new Object[]{"arg0"})