J’ai récemment eu l’occasion de travailler avec Weblogic Portal 10  (WLP10) dans le cadre d’un projet faisant une utilisation intensive de sa gestion de contenu (CMS). Je vous propose de vous faire partager mon expérience avec ce produit.

Autant l’annoncer tout de suite, WLP est très facile à prendre en main. L’IDE spécifique Workshop a disparu, remplacé par un Workspace Studio constitué d’Eclipse et d’un plug-in BEA offrant des vues intéressantes (PageFlow, Server) et des outils plus qu’utiles pour le développement (création assistée de PageFlow, Control, Portlet, liens avec la CMS et domaines Weblo, édition de propriétés…), le tout sans dérouter le développeur java lambda heureux de retrouver son environnement de travail habituel.

De manière générale, Workspace Studio doit être vu comme une sorte de boîte à outils pour le développement d’applications portail, qu’elles soient orientées CMS, Collaboration ou autre, WLP proposant des portlets génériques, taglibs, API ou autres outils pour n’importe quel type de portail.

Je passerai rapidement sur le développement de portlets avec WLP tant celui-ci est facile et la documentation netui-beehive, le framework utilisé par WLP, riche et complète (cf http://beehive.apache.org).

Je tiens plus à m’attarder ici sur la CMS BEA et les outils offerts par WLP pour l’exploiter au mieux.

Commençons par la CMS proprement dite et sur les possibilités qu’elle offre :

Le développeur Java utilisant l’API java.net se retrouvera tôt ou tard confronté à un cas récurrent : l’accès à un service en SSL. Attention je ne parle pas uniquement de HTTPS mais de tous les protocoles ayant une déclinaison SSL : IMAPS, POP3S, SMTPS, LDAPS, … les cas ne manquent pas.

À partir de ce moment le développeur se trouve en face de 2 situations :

  • Le serveur dispose d’une certificat à jour et émis par une autorité de certification connue par la JVM. Tout se passe normalement en utilisant la SSLSocketFactory fournit en standard.
  • Le certificat du serveur distant ne répond pas à ces caractéristiques. Dans l’immense majorité des cas il s’agit de certificats auto-signés. À ce moment, l’API java.net vous refusera la connexion à ce serveur en lançant une SSLHandshakeException souvent noyée dans une pile d’exécution incompréhensible.

Pourquoi ce comportement? On touche là aux fondations de la signature numérique : la chaîne de confiance. Si un tiers n’est reconnu par aucun élément de la chaîne de confiance, l’identification est impossible. Dans notre cas d’utilisation cela se traduit par l’arrêt pur et simple des communications par l’API java.net.

Pourtant, le certificat auto-signé se justifie complètement dans certains cas d’utilisation, dans un environnement de développement par exemple. Pour faire face à ce problème, 2 méthodes s’offrent au développeur Java :

  • Faire reconnaître à la JVM notre tiers en tant que tiers de confiance.
  • Faire preuve de laxisme.

Mais si l’objectif recherché est le même, chacune des méthodes agit à des niveaux différents et présente à ce titre des caractérisques singulières qu’il faudra prendre en considération.

Après plusieurs années de développement, Tapestry 5 pointe tout doucement le bout de son nez : la version 5.0.16 sera en effet marquée comme Release Candidate. C’est le moment oppportun pour faire une présentation rapide de ce framekwork, trop méconnu à mon goût.

Mais c’est quoi Tapestry?

Tapestry est un framework open-source pour le développement d’applications Web en Java au même titre que ses confrères les plus connus: Struts et JSF. Comme ce dernier, il s’agit d’un framework de type component-centric (à opposer à action-centric).

Maven contient une bizarrerie, que certains qualifieront à juste titre de bug. Sans le plugin maven-incremental-plugin, le build dans Maven ne peut pas être executé de manière incrementale car le résultat peut dans certaines situations se reveler incorrect.

Description du problème 

Considerons le projet suivant :

module-parent

   |--- module-api

   |--- module-impl

Le module module-parent contient 2 sous-modules : module-api et module-impl.

Le module module-impl contient une classe ProcessImpl qui implemente l’interface Process définie dans module-api.

Nous lancons la commande "mvn install" sur le projet parent. Tout marche parfaitement. Nous modifions la signature de l’interface Process dans module-api sans répercuter les changements sur ProcessImpl de module-impl.

Nous re-lançons une installation du projet sur module-parent avec la commande "mvn install".

Le Paris Java User Group organise le Mardi 14 octobre une présentation OSGi à 19H15 dans les locaux de l’ISEP.

www.parisjug.org/xwiki/bin/view/Blog/PresentationOSGiAuParisJUG

L’occasion de revenir sur cette norme.

OSGi est une norme issue de l’informatique embarquée, qui, à force de faire son chemin arrive dans le monde JEE en permettant de répondre à des problématiques concrètes.

Citons par exemple la possibilité de déployer des versions différentes d’un service sur un même serveur, la découverte à chaud des dépendances et la mise à disposition de services partagés.

Ainsi, beaucoup d’environnements de développement commencent à implémenter cette norme (Eclipse depuis la version 3)  pour la gestion de leur plug-in.

SpringSource va encore plus loin dans la démocratisation de cette norme avec son serveur d’application dmServer respectant OSGi et offrant des outils de mise en oeuvre de la norme. En plus de ça, SpringSource propose une liste de bibliothèques standards du monde JEE, re packagées pour respecter la norme OSGi offrant ainsi la possibilité aux nouvelles applications OSGi de les utiliser directement.