Discussion :

[BugFactory]

Bonjour,

je cherche à trouver toutes les classes implémentant une interface.

La méthode Class.getInterfaces() permet de trouver toutes les interfaces implémentées par une classe. Je veux faire l'inverse : trouver toutes les classes implémentant une interface.

Quelqu'un sait-il comment faire?

Cordialement,

[adiGuba]

Salut,


Ce n'est pas possible tel quel. Que veux-tu faire précisément ?

a++

[JeitEmgie]

Salut,


Ce n'est pas possible tel quel. Que veux-tu faire précisément ?

a++

non trivial ne veut pas dire impossible…

ce n'est ni simple ni rapide…
mais il est parfaitement possible de scanner un bytecode pour détecter ce genre de choses…
ou d'avoir son propre class loader pour tracker les classes recherchées…

la solution dépendra du contexte…

regardez déjà du côté de http://jboss.org/javassist/ …

[adiGuba]

Sauf que c'est super lourd à mettre en place, puisqu'il faudrait charger toutes les classes du classpath

Il y a surement une solution alternative qui permettrait de résoudre son problème, mais pour cela il faut savoir ce qu'il veut faire !

a++

[BugFactory]

Bonjour et merci pour vos réponses. Effectivement, Javassist a l'air très intéressant, mais je ne pense pas que ce projet me laissera le temps d'apprendre quelque chose d'aussi complexe pour si peu. Je l'étudierai probablement plus tard, par curiosité, à moins de trouver un code près à servir.

J'espère que vous aurez la patience de lire mes explications. Accrochez vous, c'est parti.

Je commence un projet utilisant les EJB. Le problème, c'est que le chef de projet n'aime pas avoir d'annotations dans les entités, car on utilise le modèle à plusieurs couches et les annotations font partie de la couche persistance.

La solution est d'avoir pour chaque entité un bean dépourvu de toute annotation, et un décorateur de ce bean avec toutes les annotations. On a également une interface commune au bean et au décorateur, et une autre interface commune à ces décorateurs. De plus, les décorateurs doivent avoir deux constructeurs : un sans paramètre créant un nouveau bean et un autre prenant en paramètre le bean à utiliser.

Par exemple, pour une entité "Info" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
// L'interface des décorateurs EJB
public interface IEjbBeanWrapper<T> {
	T getBaseBean();
}
 
// L'interface de l'entité
public interface IInfo {
	public Integer getId();
	public void setId(Integer id);
 
	// Autres champs...
}
 
// Le javabean
public class InfoImpl {
	private Integer id;
	// Autres champs...
 
	public Integer getId() { return id; }
	public void setId(Integer id) { this.id = id; }
	// Autres champs...
}
 
// Le décorateur EJB
@Entity
public class InfoEjb implements IEjbBeanWrapper<IInfo>, IInfo {
	private IInfo baseBean;
 
	public InfoEjb() {
		this.baseBean = new InfoImpl();
	}
 
	public InfoEjb(IInfo baseBean) {
		this.baseBean = baseBean;
	}
 
	@Transient
	public IInfo getBaseBean() {
		return this.baseBean;
	}
 
	@Id
	public Integer getId() {
		return baseBean.getId();
	}
 
	public void setId(Integer id) {
		baseBean.setId(id);
	}
 
	// Autres champs...
}

Toujours là? Les DAO peuvent donc enregistrer une Info en l'emballant dans le décorateur, via son constructeur prenant le bean de base en paramètre, et en enregistrant le décorateur comme si c'était une enité. Pour charger une info, on obtient du persistenceManager un InfoEjb dont il suffit d'utiliser la méthode getBaseBean.

Ca se complique si un bean en référence un autre. Si un bean A a une propriété b de classe B, en chargeant A depuis la base, on obtiendra un décorateur AEjb. On peut obtenir le bean de classe A grâce à AEjb.getBaseBean(). Mais la propriété b de la classe A contient elle-même un BEjb! On peut bien sûr obtenir b sous forme de B grâce à BEjb.getBaseBean().

Multipliez celà par le nombre d'entité et de relations entre entités du projet, et vous comprendrez pourquoi je cherche à automatiser l'emballage et le déballage.

C'est là que l'API de reflexion de Java m'est utile. Pour déballer une entité, j'ai deux choses à faire:
1. Appeler getBaseBean sur le Wrapper pour avoir le bean.
2. Invoquer tous les getters du bean. Si ils renvoient un wrapper, ce qu'on peut tester avec instanceOf IEjbBeanWrapper, le déballer à son tour (il y a donc récursivité) puis utiliser le setter du premier bean pour remplacer le wrapper par le second bean.

C'est l'opération inverse qui pose problème : l'emballage. Si je peux facilement tester qu'un objet est un wrapper en vérifiant si c'est une instance de IEjbBeanWrapper, je n'ai pas cette possibilité pour reconnaître un bean de base. Et je ne peux pas créer une interface à implémenter par les beans de base, puisque le but est que ces beans n'ait justement aucun code spécifique à la persistence.

C'est pourquoi j'ai imaginé chercher toutes les classes implémentant IEjbBeanWrapper. Si je les trouve, je peux utiliser l'API de réflexion pour connaître le type de retour de leurs méthodes getBaseBean. Je peux ainsi établir la liste exhaustive des beans de base avec leur wrapper, ce qui résout le problème précédent.

L'alternative est "d'enregistrer" tous les wrappers à la main, mais je préférerai limiter au maximum le travail des développeurs des entités.

Voilà, j'espère avoir été compréhensible à défaut d'être bref.

[JeitEmgie]

AspectJ, cglib, javassist

[Heimdal]

Est-ce qu'un packaging adapté et/ou une bonne règle de nommage ne ferait pas l'affaire?

[BugFactory]

Bien sûr, j'ai pensé à imposer un package pour les beans, un autre pour les wrappers, et imposer que nom du wrapper = nom du bean + "Ejb". Mais je ne me fais aucune illusion quant aux chances des normes de développement d'être respectées de moyen à long terme.

Je n'ai pas trop envie non plus d'introduire de nouvelles dépendances comme Javassist, Cglib et AspectJ.

C'est le temps qui sera le facteur de décision, je pense. Si je le peux, j'essaierai avec Javassist, sinon, j'utiliserai la règle de packaging... avec un test lançant une exception si elle n'est pas respectée!

Merci à tous pour toutes ces pistes. Je vais laisser le sujet en l'état pour un moment au cas où il y aurait de nouvelles idées, puis je reviendrais le mettre en résolu.

[dingoth]

Remplace le chef de projet (et je suis sérieux) ou file-lui de la doc pour lui montrer l'intérêt des annotations.

[CyberChouan]

Remplace le chef de projet (et je suis sérieux)

Sur le terrain, j'ai du mal à voir un développeur (aussi qualifié soit-il, le problème n'est pas là) réussir à remplacer son chef de projet en faisant en sorte que tout ça se passe bien (ambiance du projet, hiérarchie de l'entreprise, etc.)

[tchize_]

t'as plusieurs possibilités

1) la factory: tu centralise toutes les opérations dedans et tu a simplement une méthode emballer(ejb) (en gros). Cette factory hardcoderais le bordel. Incovénient, tu a une classe que tout le monde doit penser à mettre à jour a chaque nouvel ejb

2) comme déjà précisé, imposer une simple règle de nommage. T'as plus qu'à aller charger la classe MachinWrapper. C'est franchement pas si dur à imposer et si ca fait chier tes collègues... Qu'il aillent voir l'analyste qui a pondu une horeur pareille de wrapping/dewrapping joyeux à la volée.

3) comme déjà annoncé, des outils comme cglib. Ca introduit une pseudo dépendance (je dit pseudo car si t'as des ejb, t'as probablement déjà de la persistance et donc probablement aussi déjà hibernante derriere, et cglib fair partie des dépendances d'hibernate :p). Mais c'est assez long à apprendre et invasif. De plus tu pourra abandonner les wrappers, ceux-ci étant généré au vol par cglib.

4) Je suis pas expert en JPA, mais il me semble que l'on peu simplement remplacer les annotation par un fichier de config contenant la meme info. C'est plus chiant à gérer au jour le jour mais ca évite de te tapper les wrapper (si je dit une connerie, les expert de l'EJB, rattrappez moi)


5) Puisqu'un analyste a eu la bonne idée de considérer qu'il fallait autant de couches sur un ejb, je suppose que ce meme analyste a déjà la réponse à ta question du comment emballer / déballer facilement tout!


Entre nous, je ne comprend pas quel est le gain de splitter InfoImpl et InfoEjb. Clairement l'objet Info est destiné à être un EJB, alors pourquoi pas l'annote directement? De plus, toutes cette procédure de wrapping / dewrapping d'un EJB qui est en réalité un décorateur, même si t'arrive à le résoudre proprement, je te promet des belles prises de tête à te demander pourquoi la couche de persistence rale à un moment ou un autre parce que c'est pas ça qu'elle t'avais filé au début (par exemple :p). Sans compter que ca va plomber à crever les performances. Et je te promet que tu va être au septième ciel pour gérer les collections et l'héritage entre les entités
En dehors du cadre des EJB, j'avais déjà fait la gymnastique du wrapping / dewrapping sur des objets. J'avais à l'époque seulement une dixaine d'objets différents à gérer. Après 3 semaines de travail, je peux te garantir que j'avais un résultat médiocre et bancal. J'ai tout foutu à la poubelle et recommencé l'analyse pour me passer de ces wrappers. Et la j'avais pas le problème que tu va avoir. Tu va recevoir aucune de tes classes d'origine de l'entitypersister. Tu va recevoir des sous classe décorée par l'entitypersister pour pouvoir faire le lazyloading. Et lazyloading + ton wrapper à toi, ca sent le joyeux conflit d'intérêt

[dingoth]

On en revient donc au problème n° 1 : le chef de projet.

Je sais pas comment ça fonctionne chez vous mais chez nous, c'est le chef de projet qui analyse et file les infos dont on a besoin et le développeur qui a la main mise sur le code, et le code complet ! Le chef de projet n'a même pas besoin de savoir qu'on utilise des annotations ; il ne connaît même pas les dépendances aux APIs qu'on a : il sait juste qu'on tourne sur du Weblogic qui tourne sur Java.

Si j'enlève le problème n° 1, je pense alors à Guice qui est un framework d'injection de dépendance gérant de manière assez intuitive l'AOP et qui regroupe les solutions 1 et 3 de _tchize. La seule contrainte est d'enregistrer chaque EJB-sans-annotations dans une classe Module spécifique et il fait une grosse partie du boulot d'encapsulation,

[BugFactory]

Je suis parfaitement conscient des problèmes causés par cette architecture ainsi que de son absence totale d'intérêt. Mais d'après mon expérience, les décisions techniques sont rarement prises pour des raisons techniques. Les raisons sont généralement commerciales ou hiérarchique. Dans ce cas précis, le chef de projet bien que par ailleurs compétent essaye d'appliquer une architecture qui a fonctionné par le passé, sans se rendre compte qu'elle est obsolète. Et oui, j'ai essayé de le persuader : peine perdue. C'est moi qui ai demandé les EJB et il ne les connait pas bien, mais il doit quand même diriger le projet : mettez vous à sa place. Je suis obligé d'accommoder les demandes de la hiérarchie, en essayant de limiter la casse. Comme sur tous les projets sur lesquels j'ai travaillé dans toutes les boîtes où j'ai travaillé.

C'est moi, l'analyste qui a eu cette idée de wrapping à la volée. Puisque je suis obligé de séparer malgré moi le wrapper EJB et l'implémentation, je veux que ce soit l'architecture qui s'en charge. Nous avions déjà utilisé une architecture similaire sur un autre projet (avec un autre chef de projet) mais il fallait faire l'emballage / déballage à la main dans chaque DAO. Ca nous fait perdre un temps fou. D'autant plus que c'est un code souvent complexe et qu'une partie du code a été écrite par des développeurs junior. Code que j'ai bien sûr dû maintenir. Évidemment, les délais résultant avaient été de ma faute. C'est pourquoi je veux une solution globale : je n'aurais pas à maintenir autant de versions de ce code qu'il y a d'entités.

Par ailleurs, je ne peux pas me permettre d'insister davantage. Chaque "victoire" où j'obtiens une décision en ma faveur me coute cher en réputation. Par exemple, on m'a demandé d'améliorer l'interface d'une application en JSF utilisant MyFaces 1.1. Pour pouvoir utiliser RichFaces, j'ai voulu passer à MyFaces 1.2. Évidemment, je suis obligé de me battre avec toutes sortes de conflits de version et on m'en veut pour ça. Ça revient à se faire reprocher d'utiliser une camionnette pour un déménagement parce qu'elle a eu une crevaison alors qu'au départ on m'avait demander de déplacer une armoire normande avec un vélo, mais c'est comme ça.

Bref, ceci pour vous dire qu'il est inutile de se plaindre de ce fonctionnement, que le chef de projet n'est PAS incompétent et qu'il reste à se concentrer sur le projet.

[BugFactory]

4) Je suis pas expert en JPA, mais il me semble que l'on peu simplement remplacer les annotation par un fichier de config contenant la meme info. C'est plus chiant à gérer au jour le jour mais ca évite de te tapper les wrapper (si je dit une connerie, les expert de l'EJB, rattrappez moi)

C'est ce que je voulais faire, et le chef de projet aussi. Malheureusement, tout le monde utilise les annotations et je n'ai pas pu trouver de documentation sur ce sujet : toutes mes recherches aboutissent sur des EJB2 ou les annotations.

[tchize_]

Hors sujet mais

Par exemple, on m'a demandé d'améliorer l'interface d'une application en JSF utilisant MyFaces 1.1. Pour pouvoir utiliser RichFaces, j'ai voulu passer à MyFaces 1.2.

J'utilise ici richfaces sur un projet JSF 1.1 sans aucun soucis. D'ailleur l'upgrade JSF 1.1 -> JSF 1.2 et problématique car une partie de l'api a changé et on a plein de composant custom



Pour revenir à ton cas, les possibilités ont été exposées. A partir du moment ou on prend des EJB, je vois pas pourquoi vouloir tapper les annotation a l'extérieur, puisque les annotation font partie de l'EJB. Si c'est un problème de vouloir séparer la persistance de la partie "logique" de l'EJB, pourquoi ne pas avoir des AbstractClass du coté logique, et une implémentation de cette abstract du coté EJB. Ainsi l'ejb n'a plus que les annotations. Mais comme le parent est abstract, t'as la garantie que personne ira l'instancier directement.

[BugFactory]

J'utilise ici richfaces sur un projet JSF 1.1 sans aucun soucis. D'ailleur l'upgrade JSF 1.1 -> JSF 1.2 et problématique car une partie de l'api a changé et on a plein de composant custom

J'aurais voulu savoir ça plus tôt...

Les abstract ne sont pas possibles : le client doit pouvoir créer des nouvelles instances.

[tchize_]

pour faire clair, le problème de base c'est bien qu'on ne veux pas d'annotation dans la classe "coté client"? Si c'est le cas, je viens de fouiller un peu, tu peux remplacer en EJB3 les annotation par des fichiers persistence.xml, orm.xml et ejb-jar.xml que tu fournis à ton conteneur ejb. Ca t'évite la gymnastique des wrappers tout en permettant de séparer les entité de leur persistance...

[BugFactory]

Oui, mais comme je le disais plus tôt, où donc est la doc pour les EJB3 ?

[tchize_]

http://java.sun.com/products/ejb/docs.html

par contre, on trouve plus d'infos sur le net en tappant "JPA without annotations" qu'en tappant "EJB3 without annotation"

[BugFactory]

Eh bien, merci à tous pour votre aide. Je discuterai de la méthode à employer avec mon chef de projet... dans quinze jours, à mon retour de vacances que j'avais repoussées pour ce projet.

Je mets le sujet en résolu. Au revoir.