Récupération des stubs

Version imprimable

Voir 40 message(s) de cette discussion en une page

27/10/2005, 10h56
nana1

Récupération des stubs

Salut,
J'aimerai savoir si quelqu'un peut m'expliquer comment je peux faire pour récupérer les stubs d'un EJBs et la package contenant ces stubs?
quel est le chemin où trouver les stubs et le package contenant les classes stubs?

J'aimerai pouvoir - télécharger les stubs contenant les méthodes exportées (appelées remote) et charger avec le class loader le package contenant les stubs? mais comment faire?

merci de votre aide!!!
27/10/2005, 14h43
mauvais_karma

les as n'utilisent pas tous les stub
le seul que je connaisse est jonas
28/10/2005, 11h23
nana1

mais je ne comprends pas bien... a quoi sert le codebase? comment l'utiliser dans le cas des EJBs dans ce cas?

merci
28/10/2005, 12h04
ego

Que veux-tu faire exactement ?
Exprime bien ta problématique avant de donner une solution, cela nous aidera à mieux de conseiller
28/10/2005, 12h09
nana1

Ok.
Concrètement j'aimerai pouvoir invoquer un EJB a distance sans avoir au lancement de l'application mon EJB dans mon classpath.
Pour se faire on m'a conseillé d'utiliser le codebase afin de récuper de manière dynamique les classes de l'EJB...
Alors je ne sais pas ce qui est réellement possible : récupérer les classes, les stubs, ou le jar? puis
Et je ne sais pas comment utiliser le codebase dans le cadre des EJB... ce que je dois faire etc..
:cry:
28/10/2005, 13h05
Alwin

C'est moi qui t'ai parlé du codebase et je te l'ai donné pour piste, pas comme conseil infus :)
Le codebase permet, dans le cadre du RMI, de télécharger automatiquement les classes des stubs lors du narrow !
celà n'enlève en rien l'obligation de ton coté d'avoir l'interface des EJB que tu invoque !

Reprennons, ormis le fait que tu veuille, de manière standard, lister les EJB dispo d'un SA, être indépendant du SA, que désire tu faire ?
Utiliser les méthodes des EJB ?

Si tel est ton désir, je préfère te conseiller la chose suivante : stop !
Tu t'expose à d'énormes dificultés qui dépassent de loin le cadre de J2EE.
Tu vas devoir taper dans les spécificités des SA

- tous ne sont pas standard sur le protocole (RMI/IIOP)
- les EJB ne sont pas interopérables en l'état (recompilation des stubs client dans le meilleur des cas)
- etc...

Acceder à la liste dans le naming oui, c'est simple, mais le naming n'est qu'un annuaire, rien de plus, ce n'est pas le SA !
Si tu cherche à la clef "java:comp/env/" tu vas trouver les datasources, les queues et topics JMS et des tonnes de choses intéressantes.
Quand j'ai besoin de faire communiquer des process sifférents, j'y stock moi même des informations (plutôt que de me battre avec du partage de session...)

Donc, peut tu nous expliquer, et sans entrer dans des considérations technique, ce que tu désire faire ? quel est ton cahier des charges.

Cordialement
28/10/2005, 14h04
nana1

Ok je vous explique ce que je dois faire : attention il s'agit la d'une étude technique et c'est bien pour ca que j'ai des difficultés...
Le but est de pouvoir invoquer de manière la plus générique possible un EJB a distance....
Et comme on souhaite que ce soit le plus générique possible on ne veut pas créer une application cliente qui connaisse a l'avance quel EJB elle va invoquer...
Bon maintenant je n'ai pas de cahier de charges fixe, justement je dois proposer les solutions possibles pour pouvoir le faire et entre autre quels sont les paramètres ou pré requis obligatoires! Mais je suis complètement perdue :(
J'espere avoir été assez claire, dites moi sinon je reprends...

merci
28/10/2005, 17h28
ego

Je ne suis pas assez expert côté spec. EJB mais si tu déploies tes EJBs avec le support de IIOP et si tu publies les interfaces CORBA des EJBs dans l'Interface Repository, tu as la notion de DII (Dynamic Invocation Interface) dans CORBA.
Avec DII, tu peux faire de l'invocation dynamique de composants CORBA, voir faire de l'introspection des interfaces.

Je n'arrive pas à trouver qq chose d'équivalent "full EJB" sur le web alors....Ce que l'on trouve, c'est aussi l'invocation dynamique de WebServices dont le EndPoint est un EJB mais bon, c'est du CORBA à la sauce XML/WS.

Maintenant, si tu n'as pas la main sur le déploiement des EJBs, je n'ai personnellement rien trouvé.
31/10/2005, 11h24
nana1

Et ben!! tout d'abord merci de ton aide!
Bon ne connais absolument pas CORBA mais je peux regarder un peu dans ce sens la....
Tu me dis :

Citation:

Maintenant, si tu n'as pas la main sur le déploiement des EJBs

Tu veux dire quoi? Certes concretement a l'arrivée ce n'est pas moi qui vais déployer les EJB invoquer, mais les conditions de déploiement peuvent etre un pre-requis de l'application... Qu'est ce qu'il faudrait pour que cela fonctionne?
Sinon concrètement qu'est ce qui me bloque pour utiliser le codebase rmi? Quel est le problème exactement, je n'arrive pas bien a comprendre... je ne vois pas trop comment l'utiliser mais tu m'as dit que dans tous les cas il me faudrait les interfaces c'est bien ca? mais pourquoi exactement? le codebase ne permet pas de les récupérer?? désolée je suis perdue, je ne comprends plus rien, et j'aimerai pouvoir expliquer concretement ce qui rend impossible la faisabilité de ce projet...

merci de ton aide!!

Je ne sais pas comment tu peux t'en sortir à 100% mais effectivement, on doit pouvoir utiliser l'introspection Java pour faire ce que tu veux.

Je n'ai pas encore tout vérifié mais le code suivant me permet de découvrir les interfaces puis méthodes implémentées par le proxy qui est retourné par le lookup JNDI.

Pour que cela fonction, il faut configurer le codebase (cf. http://java.sun.com/j2se/1.4.2/docs/.../codebase.html)

Ce que je n'ai pas testé c'est l'utilisation de l'introspection pour faire un appel dynamique en utilisant le proxy mais faire ce test n'est pas difficile.
Ma question est plutôt : que vas-tu présenter à l'utilisateur ? Comment faire efficacement le tri entre les interfaces implémentées par le proxy (je ne sais pas si j'ai tout testé avec mon test "javax") et les méthodes fournies par ton EJB (notes que l'on récupère la Home via le lookup et non l'EJB lui-même; d'où la recherche de la méthode create).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/* Generated by Together */
 
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
//import CommandHome;
//import Command;
import java.util.Properties;
import java.lang.reflect.Proxy;
import java.lang.reflect.Method;
 
public class ClientClass {
    public static void main(String[] argv) {
        try {
            Properties props = System.getProperties();
            props.put(Context.PROVIDER_URL, URL);
            props.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
            Context initial = new InitialContext(props);
            Object objref = initial.lookup(JNDI);
            if (Proxy.isProxyClass(objref.getClass())) {
                System.out.println(objref.getClass().getName());
                Class[] interfaces = objref.getClass().getInterfaces();
                for (int i=0;i<interfaces.length;i++) {
                    System.out.println(">> " + interfaces[i].getName());
                    if (!"javax.".equals(interfaces[i].getName().substring(0,6))) {
                        Method[] ms = interfaces[i].getMethods();
                        for (int j=0;j<ms.length;j++) {
                            System.out.println("     -- " + ms[j]);
                            if ("create".equals(ms[j].getName())) {
                                Class o = ms[j].getReturnType();
                                Method mo[] = o.getMethods();
                                for (int k=0;k<mo.length;k++) {
									System.out.println("       ** " + mo[k]);
                                }
                            }
                        }
                    }
                }
            }
            //CommandHome home = (CommandHome)PortableRemoteObject.narrow(objref, CommandHome.class);
            //Command aCommand = home.create();
            // write your test code here
            //aCommand.method1();
            //aCommand.remove();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
 
    private final static String JNDI_FACTORY = "org.jnp.interfaces.NamingContextFactory";
    private final static String JNDI = "CommandBean";
    private final static String URL = "localhost:1099";
}

31/10/2005, 17h40
nana1

Ok merci bcp pour ton aide,c'est vraiment super... je vais tester ça!
Mais avant j'ai une question :

Citation:

Je n'ai pas encore tout vérifié mais le code suivant me permet de découvrir les interfaces puis méthodes implémentées par le proxy qui est retourné par le lookup JNDI.

C'est quoi les conséquences de passé par le proxy? concrètement ça change quoi? Tu connais les avantages ou inconvénients, les problèmes que ca pourraient poser etc...? En gros concrètement c'est quoi, stp?

Encore une question : je n'ai pas compris comment "configurer" le codebase?
et encore une question désolée : Pour le initial context factory, moi j'ai com.sun.enterprise.naming.serial.InitialContextFactory et en URL j'ai iiop://localhost:3700, ca pose problème? (NB : j'utilise le SA de sun...)

merci de ton aide, vraiment c'est sympa de prendre autant de temps, car j'suis dans uen grosse galère! :wink:
31/10/2005, 20h16
ego

Citation:

C'est quoi les conséquences de passé par le proxy?

Ben c'est le seul point d'accroche que tu as car c'est ça qui est retourné par le lookup. Il n'y a pas d'autre conséquence que d'être obligé de travailler par introspection.
Le proxy c'est un objet qui fait l'intermédiaire entre ton client et le serveur. C'est un mécanisme générique de RMI (idem en CORBA et .Net Remoting) qui explique que tu sois obligé de faire le "narrow" quand tu connais l'interface remote que ton proxy "cache / encapsule".

Pour les paramètres de connexion à ton serveur d'application, pas de soucis c'est toujours spécifique au serveur.

Pour le codebase, il faut que tu regardes la doc de ton serveur. En Java de base, il faut déclarer la propriété java.rmi.server.codebase qui doit contenir les URLs pointant vers les fichiers (.jar) contenant les "stubs" de tes EJB, ainsi que les classes apparaissant dans la signature des opérations des EJBs

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 :

Code:

-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 :
Code:

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
Code:

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 !!

01/11/2005, 15h59
ego

Pour revenir à ta description initiale du problème.
Tu parles d'appel le plus générique possible.
Qu'est ce que cela signifie ?
Est-ce que tu veux que les clients ne saches pas qui ils appelent (1) ou bien tu veux t'affranchir de la notion d'EJB côté client (2) ?

Dans le cas (1), on en revient à mes commentaires dans ma précédente réponse.
Dans le cas (2), regardes le framework SPRING (http://www.springframework.org). Avec Spring, tu peux faire un client qui appelle un objet Java classique, en fait il croit que, est c'est Spring qui fait la passerelle vers l'EJB qui est réellement appelé. Spring crée un "EJB proxy" pour tout et cela te permet même de faire des tests de ton client sans avoir le serveur d'application qui tourne.
02/11/2005, 14h07
nana1

Tout d'abord un grand merci pour ton aide!
Je vais regarder cela d'un peu plus pret pour pouvoir ensuite certainement te poser d'autres questions et te tenir au courant de mon avancement...
Je peux déjà repondre a une de tes questions :
ce que le projet devait initialisement faire : liste les ejbs présents sur un SA (dont on passe les parametres) (ca j'arrive a le faire) puis par exemple sur sélection d'un ejb de la liste pouvoir lister les différentes méthodes de cet ejb disponibles et invoquer une méthode de l'ejb.
Voila, maintenant pour ce qui est de l'intéret.... ca par contre j'suis pas encore persuadée personnellement qu'il y en ai un.

ah oui encore une question quand je lance ma JVM avec la ligne de commande que tu m'as fourni j'ai une erreur :

Citation:

Exception in thread "main" java.lang.NoClassDefFoundError: =L:\java\mysec/policy

t'as une idée?

merci encore de ton aide!
02/11/2005, 14h15
ego

Mon fichier s'appelle mysec.policy et non mysec\policy
02/11/2005, 15h36
nana1

Oui je sais mais c'est justement ce qui est étrange : j'ai crée un fichier que j'ai nommé mysec.policy et j'ai cette erreur la... :(
02/11/2005, 16h14
ego

Quelle est ta ligne de commande exacte ?
02/11/2005, 16h44
nana1

Bon ben maintenant je comprends plus rien ca ne marche plus du tout : je fais :

Citation:

java -Djava.security.manager -Djava.security.policy=L:\java\mysec.policy

et la il me dit que l'usage de la commande java n'est pas bonne :cry: j'comprends pas ce que je dois mettre...
02/11/2005, 17h20
ego
Essaye avec des "
Code:

1 2 java -Djava.security.manager -Djava.security.policy="L:\java\mysec.policy"
Sinon, mets le fichier mysec.policy dans le répertoire d'où tu lances la commande java et dans ce cas mets
Code:

1 2 java -Djava.security.manager -Djava.security.policy="mysec.policy"

Voir 40 message(s) de cette discussion en une page