AnotherGeekWebsite

Bien que LDAP soit un protocole incontournable et bien établi, se lancer dans le développement d'une application s'interfaçant avec une annuaire LDAP s'apparente souvent à un parcours du combattant. A cela plusieurs raisons :

• La notion d'annuaire peut d'abord paraître bien vague.
• Vous voulez des informations sur LDAP? La meilleure source de documentation à ce sujet reste sans aucun doute les différentes RFC traitant du sujet. Les autres sources de documentation sont souvent soit trop obscures, soit trop succintes. Le bouquin LDAP, Administration Système est également une bonne source d'informations.
• Le développeur moyen a l'habitude de s'interfacer avec une base de données. Il a alors tendance à essayer d'appliquer ses connaissances à un service d'annuaire. Malheureusement pour lui, un service d'annuaire est bien différent d'un système de gestion de données relationnel aussi bien dans son fonctionnement que dans son implémentation. Pour comprendre les différences entre ces 2 types de services, je vous invite à jetter un oeil sur l'article Wikipédia dédié.
• Pour tout développeur JAVA débutant, la découverte de l'API JNDI s'apparente à un vrai cauchemar. Le niveau d'abstraction nécessaire à ce type de librairie (JNDI peut aussi bien être utilisé pour faire des requêtes LDAP, DNS ou récupérer des informations concernant un système de fichier - http://java.sun.com/products/jndi/serviceproviders.html) amène à beaucoup de confusion. On perd en clarté ce qu'on gagne en puissance.
• Il existe une pléthore d'outils, de documentation pour accèder à une base de données ; beaucoup moins lorsqu'il s'agit d'un annuaire LDAP.

Ayant été confronté à ces différents problèmes trés récemment, j'ai dû faire la démarche de tester les différentes solutions qui s'offrent à moi pour faciliter l'interfaçage de mon application JAVA avec un fournisseur LDAP.

• Le fournisseur de service LDAP 'incontournable' reste OpenLDAP (sauf besoin particulier comme Active Directory). Il est tout de même préférable de le garder pour l'environnement de production et de se tourner vers Apache Directory Server pour l'environnement de développement.
• Oublier JNDI tant que vous pouvez, l'API est complexe, impose un niveau d'abstraction élevé : rien de tel pour s'emmêler les pinceaux. Je recommande chaudement Spring LDAP. Certes il faut ramener Spring, mais de mon point de vue c'est dorénavant quasiment toujours le cas sur les projets sur lesquels je bosse.
• JXplorer ou LDAPStudio. Le premier tient plus du choix historique avant que je ne découvre LDAPStudio qui vous procure un atelier complet dédié au développement LDAP (browser, schema browser, schema editor, etc).

À venir bientôt un article sur l'intégration d'ApacheDS avec Spring LDAP.

Vous avez décidé de faire un audit de code de votre projet Java / J2EE grâce à Checkstyle (par exemple) et ce dernier vous indique que vos sources comportent des espaces superflus en fin de ligne... Plutôt que de tous les supprimer à la main ou de vous lancer dans la recherche d'une regexp et dans des manipulations ésotériques en ligne de commande pour les faire disparaître, il existe des solutions plus simples ;) Bon forcément, ça fait moins geek hein !

Si vous utilisez Eclipse, il existe le plugin AnyEdit qui offre, entre autres, cette fonctionnalité. Il est possible d'installer le plugin directement depuis Eclipse, la procédure étant décrite sur le site du plugin. Une fois le plugin installé et votre workspace redémarré, il faut aller vérifier que l’option adéquate est bien activée dans les préférences du plugin. Pour cela, Window > Preferences > General > Editors > AnyEdit Tools. La case Remove trailing whitespaces doit être cochée. Ainsi, quand vous enregistrerez un fichier dans l'éditeur, tous les espaces inutiles seront supprimés.
NB: pour ma part, j'ai testé le plugin en version 1.6.1.3 avec Eclipse 3.2.

Sous Workshop 8.1, la suppression des espaces en trop est une fonctionnalité de base de l'éditeur, mais elle n'est pas activée par défaut. Pour l'activer, Tools > IDE properties... > Editor. Dans le cadre de droite, en bas de la section Source view options, choisissez From all lines dans la liste déroulante Trim trailing whitespaces on save:. Ces fameux trailing whitespaces disparaîtront comme par magie lors de la sauvegarde d'un fichier !
NB: cette fonctionnalité est présente dans la version 8.1 SP4 de Workshop, elle devrait également se retrouver dans les autres versions, tout du moins dans les différentes déclinaisons de la branche 8.1.

Dans $MAVEN_HOME/bin, ajouter un fichier mvn-debug

#!/bin/sh
echo ""
echo Debug mode on port 8000
echo ""
 
 
export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"
 
 
. `dirname "$0"`/mvn
exec  "`dirname "$0"`/mvn" $QUOTED_ARGS
 
unset MAVEN_OPTS

Rendre le bordel exécutable

Démarrer maven en mode debug

$ mvn-debug <target>
Debug mode on port 8000

Le processus attendra la connexion d'un débuggeur avant de poursuivre.

Qui ne s'est jamais arraché les cheveux à essayer de résoudre un problème d'encodage de caractère?

Tiens j'en viens tout juste de faire les frais

Contexte

• J2EE, Liferay, Struts
• Tomcat sur les postes des développeurs (allez faire tourner Liferay sous Weblogic et vous comprendrez pourquoi...)
• Weblogic en production

Symptômes

• impossible de récupérér correctement une chaîne UTF-8 passée en valeur de paramètre dans une URI sans transcodage si cette chaîne contient des caractères non US-ASCII (éàè...). Mieux encore cela ne se produit que sous Tomcat.

Pourquoi?

• par défaut Tomcat transcode les paramètres d'URI vers l'ISO-8859-1.

Solution

• user des paramètres URIEncoding et useBodyEncodingForURI - voir la configuration connecteur HTTP de Tomcat - pour forcer, par configuration l'encodage utilisé dans les URI.

Pour plus d'informations au sujet des URI voir la RFC correspondante.

Petite astuce pour profiter d'Eclipse pour manager votre serveur d'applications J2EE (démarrage, arrêt, affichage des traces,...). La méthode décrite ci-dessous nécessite WTP pour fonctionner. Pour info, j'ai travaillé avec WTP all-in-one 1.5.2 (Eclipse 3.2.1 packagée avec WTP 1.5.2), mais cela devrait fonctionner pour d'autres versions.

Contrôler votre serveur dans Eclipse est assez facile: lancez Eclipse, puis dans le menu Window > Show view > Other..., déroulez l'arborescence Server et choisissez d'afficher la vue Servers. Cette dernière est positionnée par défaut en bas de votre espace de travail, aux côtés des vues Console, Problems, ... Pour ajouter un serveur, cliquez-droit dans la vue, choisissez New > Server. Déroulez l'arborescence correspondant au fournisseur de votre serveur et choisissez enfin le serveur adéquat. Les étapes de configuration qui suivent sont spécifiques à chaque serveur. Vous pouvez ajouter autant de serveurs que vous le désirez.

Une fois votre serveur correctement configuré, vous pouvez le démarrer en mode normal, en mode debug, l'arrêter, le redémarrer, y publier un projet Web Eclipse, ... Les traces du serveur s'affichent dans la vue Console, avec tous les avantages qui y sont liés (possibilité d'effacer la console, de locker le scroll, ...)

Un des avantages de cette vue Server est de proposer une vue générique pour la gestion de vos serveurs et ainsi de pouvoir s'affranchir de plugins tiers tels que celui de Sysdeo pour Tomcat. Personnellement, je l'utilise pour ne plus avoir à toucher à la ligne de commande Windows ou à Workshop 8.1 pour démarrer / arrêter Weblogic, l'IDE de BEA étant pour moi très peu attrayant (mais ça n'est là qu'un avis personnel qui n'engage que moi :p).