Pour le codebase, pas de soucis côté JBoss (c'est l'AS que j'utilis), il est configuré automatiquement.
Ensuite, c'est côté client qu'il te faut autoriser le chargement des stubs. Cela se gère via la sécurité !
Il faut lancer ta JVM avec les arguments suivants :
-Djava.security.manager -Djava.security.policy="mysec.policy"
Le fichier "mysec.policy" est un fichier déclarant certaines règles de sécurité. En l'occurrence, j'ai tout ouvert pour faire le test.
Voici le contenu du fichier :
1 2 3 4
| grant {
// Allow everything for now
permission java.security.AllPermission;
}; |
Ainsi, sans avoir les classes CommandXXX la portion de code suivante permet d'appeler l'EJB
1 2 3 4 5 6 7 8
| //CommandHome home = (CommandHome)PortableRemoteObject.narrow(objref, CommandHome.class);
//Command aCommand = home.create();
Method m = objref.getClass().getMethod("create",null);
Object aCommand = m.invoke(objref,null);
m = aCommand.getClass().getMethod("method1",null);
Object ret = m.invoke(aCommand,null);
// write your test code here
//aCommand.method1(); |
Les lignes en commentaires sont le code que l'on écrit quand on connait les interfaces des classes. Le code qui tourne utilise quand à lui l'API de Reflection Java.
Bref, ton projet est faisable mais le problème va être de savoir qu'elles méthodes appeler. D'autre part, si tu ne connait pas les classes qui sont dans la signature des méthodes des EJBs, ces classes peuvent être chargées elles aussi via le codebase et les mécanismes RMI mais il va falloir trouver là aussi un moyen de dynamiquement découvrir leur structure, là pas de pb via l'API Reflection, et trouver un moyen de les créer et initialiser avant de les utiliser pour faire un appel.
Bref2, ton truc c'est bien pour faire un outil de test pour développeur mais je ne vois pas trop d'usage dans une application plus classique.
On n'a pas parlé non plus du "browsing" de l'annuaire JNDI pour connaitre les EJBs déployés !!
Partager