Version imprimable
Bonjour à tous, j'aimerais mettre en place une méthode en java me permettant d'avoir la liste de toutes les classes accessibles de mon classpath.
Je sais pas si quelqu'un a déjà été confronté à ce problème, si oui, j'aimerais bien savoir comment il a procédé.
Merci d'avance!!
Ensuite à partir de là tu sépara chaque élément, pour tout ce qui représente des ficheir jar, tu les ouvre avec jarfile, tu scanne leur contenu, tu lit aussi au passage le META-INF/MANIFEST.MF pour récupérer le Classpath: et continuer récursivement l'opération. Pour tous les dossiers, tu scanne les fichiers , sous dossier, etc. Ne marchera pas si le classpath contient des url de type HTTP, il n'existe aucun moyen de les "scanner".Code:String classPath = System.getProperty("java.class.path",".");
Salut,
Quel est l'objectif de tout ceci ???Citation:
Envoyé par yashiro
a++
En fait, je voudrais mettre en place un module de gestion des utilisateurs qui permettra à un administrateur de donner des droits à des utilisateur (ou groupe d'utilisateurs) sur des méthodes métier. De plus, ce module devra s'intégrer dans une application quelconque via l'AOP.
Pour cela, le doit pouvoir afficher à l'administrateur la liste de toutes les classes (et méthodes) métiers tagguée d'une annotation de sécurité particulière. Ce qui lui permettra d'affecter à un utilisateur ou un groupe d'utilisateur l'accès à une classe, une méthode etc...
NB:
Je sais que la première réaction sera pourquoi fais-tu cela alors qu'il ya Drools, JAAS etc...
Mais avec JAAS, j'ai pas pu résoudre ce problème (Créer des rôles dynamiquement et leur associer des droits sur des méthode ou des classes).
Par ailleur, faute de documentation sur Drools (de préférence en français), je me suit dit pourquoi pas créer mon propre outils??? Donc voilà pour mes motivations.
Pourquoi vouloir charger toutes les classes !
Il suffirait de référencer ces classes (un simple fichier texte pourrait faire l'affaire). C'est bien plus simple et plus performant ;)
a++
Drools est un moteur de règles, et serait assez inadéquat pour ce que tu veux faire.Citation:
Envoyé par yashiro
le principe de l'AOP, c'est que tu travaille de manière réactive: Une classe est utilisée, alors seulement, éventuellement, tu ajoute de la logique dessus. Scanner toutes les classes du classpath est non seulement suicidaire du point de vue performance, mais comment l'admin sera censé s'y retrouver lorsqu'il se verra présenter une liste de 5000 classes avec leurs méthodes.
En plus, tu n'as certainement pas envie que ta webapp se mette à charger toutes les classes de la swing/awt ;)
Le mieux est de fournir un fichier avec la liste des classes taggués à charger.
En réalité, le module ne présentera pas à l'administrateur toutes les classe/Méthodes mais seulement celles qui sont annotées par une annotation particulière (du genre @YashiroProtect) qui demandera comme attribut un commentaire qui représentera une sorte de présentation de l'utilité de la classe ou de la méthode. Ainsi, l'administrateur pourra décider que tel ou tel utilisateur aura accès à telle classe/méthode et l'autre pas, et ainsi lorsque un utilisateur essaiera d'acceder à une méthode, le module pourra intercepter cet appel VIA l'AOP, et déterminer si cet utilisateur est paramétré pour pouvoir appeler la méthode qui a cette signature.
Par ailleurs, je n'ai pas opté pour un fichier dans lequel le développeur déclarera ses classe métier pour la simple raison que je voudrais que l'intégration de cet outil soit faite de façon totalement transparente au développeur, ou du moins avec le moins de configuration possible. De plus un dans un fichier, je vois pas trop comment je pourrait lister de façon dynamique toutes les classes/méthodes de mon classpath, vu que celle-ci peuvent être ajoutées de façon dynamique par le système de plugin par exemple.
Doc voila en bref les raisons de mes choix.
sauf que scanner le classpath, qui plus es à la recherche d'annotation (donc en chargeant les classes) ça va avoir les conséquences suivantes
1) toutes les classes qui n'ont tien à voir avec l'application mais qui se trouvent pour une raison ou une autre dans le classpath vont être initialisée. Ceci inclus, par exemple, les classes AWT/Swing, qui vont demander l'accès à une console graphique pour certaines, impliquer le chargement du code natif derrière et , pour une application server, donc typiquement non graphique, lancer des HeadLessException en pagaille. Rajoutons aussi que ca démarrera probablement le Thread de l'EDT. Autre exemple, les api de logging, risquent de se voir initialisée avant le moment ou le programmeur avait prévu leu initalisation.
2) Si tu utilise un système de plugin basé sur un classloader, ton scan ne verra de toutes facons pas ces classes là car elle sont chargées dynamiquement
3) Toutes les classes annotées qui ne servent pas dans ta webapp pour des raisons quelconques vont quand même apparaitre.
4) Comme tu charge plein de classes en mémoire, tu va saturer immédiatement les zones mémoires réservées au code et faire exploser la consommation mémoire. Rien que pour java 5 avec les classe publiques, il y en a pour plus de 3000 classes à charger. Rajoute à ça toutes les classes private, protected, anonymous inner et en com.sun qui ne font pas partie de la javadoc.
Je ne connais aucun framework basé sur des annotation qui fasse un scan de force comme çà, et pour cause, c'est stupide à tout point de vue. Et tu ne va pas faciliter la vie de programmeur non plus, puisqu'il ne pourront plus garder dans leur code de classe temporaire, de test ou autre annotée mais qu'il ne vouraient pas rendre visible des utilisateur (pas finie, annotation pas testée, etc)
Merci de tes remarques tchize_, seulement, l'idée n'est pas d'instancier des classes, mais d'analyser via l'introspection la structure des classes du classpath pour en déceler celles qui me concernent.
Cette opération se fera de façon ponctuelle pour obtenir la liste des méthodes surveillées et cela une seule fois.
En plus, une liste d'archives à ne pas scanner sera entretenue, me permettant ainsi de ne pas scanner plusieurs fois la même archive, mais aussi de ne pas scanner les archives fournies par le JDK ou par le serveur JBoss.
En fait, j'aimerais imiter le comportement de la méthode scanClassPath du serveur JBoss (dont j'ai lu les codes dans sa distribution embarquée). Et dans cette méthode, JBoss scanne effectivement le classpath, en obtenant la liste des répertoires et archives à scanner via la propriété java.class.path, et en excluant de cette liste toutes les archives et répertoires dont le nom figure dans une fichier de chemin à exclure.
Mais je rappelle que le but n'est pas d'instancier les classes, mais plutôt d'en analyser la structure via l'introspection.
J'ai jamais dit dans ma description que t'allais les instancier, j'ai bien parlé de l'initialisation des classes, qui sera inévitable si tu fais de l'introspection dessusCitation:
Envoyé par yashiro
Un fois chargées par le classloader, les classes y restent, pas de retour en arrière possible. Encombrement de mémoire garanti si ton user ne liste pas correctement tous les jar à exclure (et de ce coté là, il aurait plus vite fait de lister les jar à inclure!)Citation:
Cette opération se fera de façon ponctuelle pour obtenir la liste des méthodes surveillées et cela une seule fois.
Donc chaque classe va être initialisé c'est inévitable. Ca veux dire que leur code sera chargé en mémoire, que tous les champs et blocs statiques seront initialisés. Ca aura pour conséquence l'initialisation de nombreuses classes en cascade utilisées par des champs statique. Je pense par exemple auCitation:
Mais je rappelle que le but n'est pas d'instancier les classes, mais plutôt d'en analyser la structure via l'introspection.
présent dans de nombreuses classes. C'est plein de loggers inutiles que tu va instancier et qui vont rester en mémoire, en plus du bytecode.Code:private static Logger log = Logger.getLogger(MaClasse.class);