Librairie d'accès a un annuaire LDAP

[Mobius]

Bonjour,

Je viens (enfin!) de publier une librairie d'accès à un annuaire LDAP.
Cette librairie permet d'effectuer simplement un mapping entre les données de l'annuaire et des classes Java.
Le but est de décrire les objets LDAP dans une interface sans avoir a s'occuper de son implémentation.

Pour ceux que ca interesse, j'ai publié les sources sur google code (projet ldapbeans)

Pour le moment seul les sources sont disponible (sous la forme d'un projet maven/eclipse). J'espère pouvoir fournir de la documentation rapidement.

Merci à tous ceux qui le souhaite (et on le courage) de me faire des retours et des critiques.

En espérant que ca facilite la vie de certains développeurs.

[deltree]

Je l'ai un peu testé, je trouve ça bien.
Je ne connaissait pas Apache DS, il n'y a pas moyen de l'initializer en dehors des test?

Sinon question détail, il y a un test qui ne passe pas :ZipFileTest.testZipFile

Suggestion sur le Mécanisme interface/Manager:
tu définis la persistence au niveau du bean interface, ce qui oblige à avoir un interface plutôt qu'un bean et donc à annoter getter et setter,
Est-ce que tu n'aurais pas pu faire comme en JPA/EntityManager: définir persistence au niveau du manager puis l'annotation au niveau de l'attribut privé du bean, quitte à calculer les noms de getter/setter?

Niveau code ce que j'ai testé:

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
 
@RunWith(FrameworkRunner.class)
@CreateLdapServer(transports = { @CreateTransport(protocol = "LDAP", port = 10389) }, allowAnonymousAccess = true)
@ApplyLdifFiles({ "monldap.ldif" })
// @ApplyLdifFiles({ "ldapbeans.ldif" })
public class MonLDAPTest {
    /*
     * ces 3 champs sont utilisés par
     * org.apache.directory.server.core.integ.FrameworkRunner.runChild
     */
    public static DirectoryService service;
    public static boolean isRunInSuite;
    public static LdapServer ldapServer;
 
 
    @Test
    public void testSimple() {
	LdapBeanManager s_Manager = LdapBeanManager.getInstance(
		"ldap://localhost:10389", "ou=system", null, null);
	LdapBeanHelper.getInstance().scanPackage("ldapbeans.bean");
 
	Person person = null;
 
	person = s_Manager.findByDn(Person.class, "cn=John Doe,ou=system");
	// person = s_Manager.findByDn(Person.class, "cn=Kim Wilde,ou=system");
	Assert.assertNotNull(person);
	System.out.println("Person : " + person.getEmployeeNumber());
    }
}
///et dans person.java
[...]
    @LdapAttribute("employeeNumber")
    String getEmployeeNumber();

ça fait du code simple et propre.

( par contre l'employeeNumber que j'ai ajouté fait planter la recherche,il renvoie null. est-ce que j'ai foiré mon ldif? )

Enfin j'encourage une suite à cet outil.

[Mobius]

Envoyé par deltree

Je l'ai un peu testé, je trouve ça bien.
Je ne connaissait pas Apache DS, il n'y a pas moyen de l'initializer en dehors des test?

on peut faire pas mal de chose avec Apache DS, entre autre s'en servire pour avoir un annuaire LDAP embarqué dans une application. C'est expliqué comment faire sur le site d'Apache DS

Envoyé par deltree

Sinon question détail, il y a un test qui ne passe pas :ZipFileTest.testZipFile

Etonnant, ca passe chez moi. Il faudrait plus de détail (du genre la stack de l'erreur) pour avancer sur le pb. Le mieux est d'ouvrir une anomalie sur le site de ldapbeans.

Envoyé par deltree

Suggestion sur le Mécanisme interface/Manager:
tu définis la persistence au niveau du bean interface, ce qui oblige à avoir un interface plutôt qu'un bean et donc à annoter getter et setter,
Est-ce que tu n'aurais pas pu faire comme en JPA/EntityManager: définir persistence au niveau du manager puis l'annotation au niveau de l'attribut privé du bean, quitte à calculer les noms de getter/setter?

J'y ai pensé mais je n'aime pas du tout l'idée de devoir écrire une pseudo-implémentation bidon. De plus, je ne vois pas beaucoup d'avantage a cet solution si ce n'est que de ne pas avoir a écrire deux fois l'annotation (une fois pour le getter et une fois pour le setter). Ca ne raccourcis pas le code puisqu'il faut ajouter l'attribut en plus de déclarer le getter et le setter.
Ce n'ai pas que je suis opposé a cette solution mais j'aimerai être un peu plus convaincu.

Envoyé par deltree

Niveau code ce que j'ai testé:

Code :

ça fait du code simple et propre.

( par contre l'employeeNumber que j'ai ajouté fait planter la recherche,il renvoie null. est-ce que j'ai foiré mon ldif? )

Encore une fois, c'est difficile de t'aider sans la stack de l'erreur ni le fichier LDIF. Tu peux ouvrir une annomalie sur le site de ldapbeans

Envoyé par deltree

Enfin j'encourage une suite à cet outil.

Merci pour tes encouragements,
Merci beaucoup pour le temps passé a tester l'outil.
Merci également pour les propositions. Si tu en as d'autres n'hésite pas a les marquer sur le site de ldapbeans (encore et toujours).

[Mobius]

Je viens d'avancer dans le développement de ma librairie.
Deux changements majeurs :
- elle ne fonctionne plus par réflexion mais génère des classes dynamiquement (génération de bytecode grace à ASM)
- possibilité de récupérer d'autre bean (et plus seulement de simple valeur comme des String ou des int)

D'un autre coté, je viens de faire des recherches qui m'ont mis un sacré coup au moral :
Je viens de trouver un projet nommé "object-ldap-mapping" qui fait a peu près ce que je voulais faire. L'approche est un peu différente et la librairie se base sur spring-ldap

Si j'ai bien compris, ca marche comme ce que disait deltree, c'est a dire une approche comme celle de JPA. (Ceci dit, je persiste a dire que mon approche permet d'écrire moins de code et évite d'écrire une implémentation inutile)

Le point positif, c'est que ca fera au moins un heureux (deltree).
Le point négatif, c'est que je doute sur le bienfondé de continuer mes travaux.