Comme une grande partie des lecteurs de ce blog, vous avez certainement déjà travaillé sur des applications web Java EE de taille variable, sur lesquelles vous avez fait un nombre indécent de redéploiements à chaque fois que vous vouliez valider des modifications fraîchement apportées. Puis vous avez dû découvrir que depuis Java 1.4, la JVM permet de faire du Hotswap en mode debug, c’est-à-dire de remplacer du code à la volée au runtime.

C’est bien, mais il y a quand même des limitations : on ne peut que modifier le corps d’une méthode déjà existante, si l’on ajoute une méthode ou une classe elle ne sera pas prise en compte. Idem pour les membres statiques, les annotation ou encore les fichiers properties accédés via un ResourceBundle.

C’est pour pallier ces manques que la société Estonienne ZeroTurnaround a développé JRebel, un outil destiné aux développeurs désirant gagner du temps dans leur cycle de développement.

JRebel, c’est quoi ?

Comme l’explique en anglais un article du blog de ZeroTurnaround, JRebel est principalement un agent à installer dans votre serveur d’applications, qui va réagir à des mises à jour de classes, ou plus généralement de ressources composant votre application. À l’aide d’un fichier de configuration rebel.xml, vous allez spécifier une liste de ressources à surveiller, par exemple des répertoires contenant des JAR et des fichiers properties. Lors du déploiement de votre application, l’agent va utiliser cette configuration pour scruter des changements dans ces répertoires (un timestamp plus récent).

Pour appliquer ces changements, JRebel introduit un classloader qui va se charger de détecter le chargement des classes, pour ensuite générer des classes anonymes grâce la génération de bytecode on-the-fly. À chaque modification d’une classe dans votre IDE, une nouvelle classe anonyme sera générée pour modifier le comportement de la classe originale, grâce à un savant mélange de JIT et de magie noire (l’article ne rentre pas trop dans les détails du fonctionnement interne, secret de fabrication oblige puisque c’est un outil commercial).

Fonctionnement de l'agent (image issue du site de ZeroTurnaround)

Au final, la perte de performances est minimisée comparé au gain de temps entrainé par le fait que l’on ne soit pas obligé de redéployer toutes les 5 minutes. Que vous utilisiez des JAR, des WAR, du Spring, Struts, Wicket ou autre Hibernate, sur des serveurs Glassfish, Websphere, JBoss, ou encore Weblogic, il y a de fortes chances que JRebel le supporte de base ou via des plugins. Et si votre framework favori n’est pas dans la liste, une API vous permet de développer votre propre plugin.

Mise en pratique

Cas simple : modification d’une méthode

Nous allons maintenant tester JRebel sur une application web type HelloWorld. Comme je l’ai déjà dit plus haut, c’est un outil commercial mais une version d’évaluation de 30 jours est disponible sur le site. L’installation est très bien expliquée par un wizard prenant en compte votre IDE et votre serveur, donc je ne m’attarderai pas sur le sujet.

J’ai choisi d’utiliser Netbeans et Glassfish pour déployer une application toute simple : une calculatrice. Je dispose d’une servlet nommée Calculator, chargée de faire des additions et des soustractions :

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
public class Calculator extends HttpServlet {



    protected void processRequest(HttpServletRequest request, HttpServletResponse response)

    throws ServletException, IOException {

        response.setContentType("text/html;charset=UTF-8");



        String operation = request.getParameter("operation");

        Integer result = null;



        if (operation != null && request.getParameter("a") != null && request.getParameter("b") != null) {

            Integer a = Integer.valueOf(request.getParameter("a"));

            Integer b = Integer.valueOf(request.getParameter("b"));



            if (operation.equals("add")) {

                result = a + b;

            } else if (operation.equals("sub")) {

                result = a - b;

            }

        } else {

            throw new IllegalArgumentException("Don't fool me, use correct parameters: a, b and operation!!");

        }



        PrintWriter out = response.getWriter();



        try {

            out.println("The result is " + ((result == null) ? "unpredictable" : result));

        } finally {

            out.close();

        }

    }

Attention, Netbeans est malin et par défaut fait du deploy-on-save. Il faut donc désactiver l’option dans les propriétés du projet pour ne pas interférer avec JRebel.

La configuration du fichier rebel.xml, à placer dans WEB-INF/classes/, va ressembler à ceci :

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>

<application

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns="http://www.zeroturnaround.com"

  xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

    <classpath>

        <dir name="D:\NetBeansProjects\WebApplication1\build\web\WEB-INF\classes"/>

    </classpath>

</application>

On demande donc de prendre à chaud tout ce qui va changer dans le répertoire où sont placées les classes compilées.

Dans les logs du démarrage de glassfish, on peut ainsi voir :

Procédons à une modification mineure du corps de la méthode processRequest() :

1
2
// On a changé le message affiché

out.println("Congratulations, the result is " + ((result == null) ? "unpredictable" : result));

Après compilation du fichier et rafraîchissement de la page dans le navigateur, on obtient immédiatement le changement :

Modification à chaud du corps d'une méthode

Dans le cas présent, JRebel a fait l’équivalent du hotswapping standard de la JVM, mais sans avoir besoin d’être en mode debug.

Un cran au-dessus : ajout de méthodes / classes

Amusons-nous maintenant dans le domaine de l’inédit. Pour satisfaire notre envie de separation of concerns, on va externaliser le code métier dans une classe différente de la servlet :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Calc {



    public static Integer add(Integer a, Integer b) {

        return a + b;

    }



    public static Integer substract(Integer a, Integer b) {

        return a - b + 2;

    }

}



// et dans la servlet :

if (operation.equals("add")) {

    result = Calc.add(a, b);

} else if (operation.equals("sub")) {

    result = Calc.substract(a, b);

}

On enregistre, on compile et on vérifie : la nouvelle classe (et indirectement de nouvelles méthodes) a été prise en compte automatiquement (pour en être sûr, on peut bidouiller l’addition pour qu’elle calcule a + b + 1 par exemple).

Et les ressources ?

Pour l’instant nous nous sommes contentés de modifier du code Java. Et si on essayait des fichiers properties ? Ca tombe bien, notre client vient justement de nous faire part de son vœu de pouvoir internationaliser le nom des opérations add et sub !

On va donc utiliser un ResourceBundle :

1
2
3
4
5
if (operation.equals(ResourceBundle.getBundle("operations").getString("add"))) {

    result = Calc.add(a, b);

} else if (operation.equals(ResourceBundle.getBundle("operations").getString("sub"))) {

    result = Calc.substract(a, b);

}

On compile, on rafraîchit et là… c’est le drame !

1
2
3
4
5
6
7
8
9
10
11
WARNING: StandardWrapperValve[Calculator]: PWC1406: Servlet.service() for servlet Calculator threw exception

java.util.MissingResourceException: Can't find bundle for base name operations, locale en_GB

        at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1521)

        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1260)

        at java.util.ResourceBundle.getBundle(ResourceBundle.java:715)

        at com.excilys.blog.jrebel.servlet.Calculator$$M$6334694c.processRequest(Calculator.java:38)

        at com.excilys.blog.jrebel.servlet.Calculator$$A$6334694c.processRequest()<generated>

        at com.excilys.blog.jrebel.servlet.Calculator.processRequest(Calculator.java:51)

        at com.excilys.blog.jrebel.servlet.Calculator$$M$6334694c.doGet(Calculator.java:65)

        at com.excilys.blog.jrebel.servlet.Calculator$$A$6334694c.doGet()<generated>

        at com.excilys.blog.jrebel.servlet.Calculator.doGet(Calculator.java:65)

Et oui, les ressources sont cherchées dans le répertoire build\web\WEB-INF\classes\operations.properties, hors comme on ne fait pas de build complet le fichier properties qu’on vient de créer ne s’y trouve pas encore . Pas de souci, on le copie à la main (ou on fait un build complet, mais c’est plus long), et là ça marche ! Remarquez au passage que les classes mentionnées dans la stacktrace ont des noms un peu bizarres, certaines sont marquées <generated> : cela correspond à ce que j’ai expliqué plus haut au sujet du fonctionnement interne de JRebel.

Zut, le client vient de décider qu’à présent, on aura des noms d’opérations en français. Pas de souci, on a juste à changer notre properties (celui dans le dossier build/, sauf si vous décidez de monitorer également la version dans src/), et les changements sont pris à chaud :

Encore une killer-feature : le plugin Spring

Comme évoqué dans les principes de fonctionnement, JRebel supporte entre autres les changements à chaud de configuration du framework Spring grâce à un plugin dédié. Voyons un peu comment ça fonctionne. Après avoir supprimé le static des méthodes de la classe Calc, j’ai décidé d’en faire un bean Spring :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"



       xsi:schemaLocation="http://www.springframework.org/schema/beans

                                   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">



    <bean id="calc" class="com.excilys.blog.jrebel.Calc" />



    <bean class="org.springframework.web.context.support.ServletContextAttributeExporter">

        <property name="attributes">

            <map>

                <entry key="calcBean">

                    <ref bean="calc"/>

                </entry>

            </map>

        </property>

    </bean>

</beans>

Ce bean est ensuite récupéré dans la servlet de la manière suivante :

Je vous passe la configuration du web.xml, elle est tout à fait standard. Cependant JRebel ne permet pas de prendre à chaud les changements dans web.xml, on va donc être obligés de redéployer notre application (mais on le fera plus après, promis ). Redéploiement et rafraîchissement de la page web, ouf, tout fonctionne normalement.

Pour tester le plugin Spring, on va introduire une modification mineure : renommer l’attribut du contexte permettant de récupérer bean.

Compilation, rafraîchissement (en ces temps de fortes chaleurs…), applaudissements. On vient de bénéficier d’une modification de la configuration de Spring sans avoir à redéployer !

Conclusion

Résumons un peu. Avec un seul déploiement (parce que je m’y suis pris trop tard, avouons-le), on a réussi à prendre en compte immédiatement des modifications de méthodes, des ajouts des classes, des modifications des fichiers properties accédés par un ResourceBundle et surtout des fichiers de configuration de framework (Spring dans cet exemple). Ça en jette, non ? Tout ça pour pas un rond si vos développement durent moins de 30 jours, sinon il faudra débourser une somme relativement modeste (189$ pour une licence annuelle standard).

Le Rebelle aussi utilise JRebel.

Petit plus pour les décideurs, à chaque démarrage du serveur, JRebel affiche des estimations sur le précieux temps qu’il vous a fait gagner, de manière à mesurer les gains qu’apportent de tels outils :

Pour aller plus loin

• Site de JRebel
• JRebel ou comment accélérer le développement
• Java Posse #306 – JRebel Interview
• Youpi ! Ca marche aussi avec Maven
• Enfin une bonne raison de se mettre à Scala

Comme beaucoup de lecteurs de ce blog, j’utilise un IDE au quotidien. Sur mon projet actuel, c’est Eclipse combiné à un serveur Websphere. Pour des raisons pratiques, je fais un tail -f des logs du serveur dans la console d’Eclipse, et qui dit serveur d’applications Java + logs en niveau DEBUG dit énormément d’informations à scanner pour trouver ce qui m’intéresse réellement (quelques Mo de logs par jour !).

Colore tes logs !

La solution que j’ai retenue pour facilement m’y retrouver, c’est Grep Console. Ce plugin pour Eclipse permet de colorier dans une console certaines parties de texte qui matchent une ou plusieurs expressions régulières. Par exemple, les WARN en orange et les ERROR en blanc sur fond rouge.

Les boites de dialogues ultra-simples de configuration de Grep Console

On voit dans la fenêtre de gauche toutes les expressions régulières que j’ai choisies de matcher et dans celle de droite la configuration de l’une d’entre elles : définition de la regexp, choix des couleurs d’arrière-plan ou d’avant-plan pour la ligne entière ou pour les groupes capturés par des parenthèses (cependant on ne peut pas imbriquer les parenthèses).

Voici le résultat dans la console d’Eclipse :

Conclusion

Simple mais efficace, je vous conseille vivement d’installer ce plugin qui permet de gagner du temps si vous avez des logs sous les yeux à longueur de journée ! Rendez-vous sur l’update site http://eclipse.musgit.com. Seul bémol, je n’ai pas encore trouvé d’astuce pour colorier d’anciens logs dans d’autres fichiers (une sorte de less coloré). Si vous avez un outil qui fait ce genre de choses, je suis preneur .

]]> http://blog.excilys.com/2010/06/30/illuminez-vos-logs-dans-eclipse/feed/ 1 http://blog.excilys.com/2010/06/30/illuminez-vos-logs-dans-eclipse/ http://feedproxy.google.com/~r/blogexcilyscom/~3/aw_n_vwndYM/ http://blog.excilys.com/2010/06/25/de-switcher-nest-pas-jouer/#comments Thu, 24 Jun 2010 22:20:38 +0000 Pierre-Yves RICAU http://blog.excilys.com/?p=2375 Amis utilisateurs de Checkstyle, avez-vous remarqué que les switch sont des sources inépuisables de complexité cyclomatique ? Sans parler de leur équivalent pour les objets, les if () {} else if (){} else if (){} else if (){} à répétition.

Parmi les reproches récurrents faits aux switch, il y a le fait qu’ils ne respectent pas le principe Ouvert/Fermé. A chaque ajout de nouvelles valeurs, il faut modifier tous les switch qui les manipulent.

Il est toujours possible de se passer d’un switch. Un moyen simple est d’utiliser une Map. Ainsi, le code suivant :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public String getMessage(int messageCode) {

    String message;

    switch (messageCode) {

        case 42:

            message = "the Answer to the Ultimate Question of Life, the Universe, and Everything.";

            break;

        case 13:

            message = "Good luck!";

            break;

        // [...]

        default:

            throw new IllegalArgumentException("Unknown code");

    }

    return message;

}

devient :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private final Map<Integer, String>  messagesByCode = new HashMap<Integer, String>();



private void initMessagesByCode() {

    messagesByCode.put(42, "the Answer to the Ultimate Question of Life, the Universe, and Everything.");

    messagesByCode.put(13, "Good luck!");

    // [...]

}



public String getMessage(int messageCode) {

    String message = messagesByCode.get(messageCode);



    if (message == null) {

        throw new IllegalArgumentException("Unknown code");

    }



    return message;

}

Cela fonctionne aussi si le switch (ou les if/else) contient du code à exécuter qui varie suivant les cas. Ainsi :

1
2
3
4
5
6
7
8
9
10
11
12
public void doAction(String action) {

    if ("syso".equals(action)) {

        System.out.println("Yeah");

    } else if ("syserr".equals(action)) {

        System.err.println("Yahoo");

    } // [...]

    else {

        throw new IllegalArgumentException("Unknown action");

    }

}

// [...]

doAction("syso");

devient (j’en conviens, des first-class functions simplifieraient le 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
private final Map<String, Runnable> actionsByName = new HashMap<String, Runnable>();



private void initActionsByName() {

    actionsByName.put("syso", new Runnable() {

        public void run() {

            System.out.println("Yeah");

        }

    });

    actionsByName.put("syserr", new Runnable() {

        public void run() {

            System.err.println("Yahoo");

        }

    });

}



public void doAction(String action) {

    Runnable runnable = actionsByName.get(action);



    if (runnable == null) {

        throw new IllegalArgumentException("Unknown action");

    }



    runnable.run();

}

// [...]

doAction("syso");

Clairement, si ce type de modification permet de se passer de switch sans modifier la signature des méthodes, elle n’est pas idéale. Une bien meilleure option ici serait de se souvenir que Java est un langage orienté Objet, et utiliser le polymorphisme pour implémenter le pattern strategy :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public interface Action {

    void doAction();

}

// [...]

public void doAction(Action action) {

    action.doAction();

}

// [...]

public class Syso implements Action {

    public void doAction() {

        System.out.println("Yeah");

    }

}

// [...]

public class Syserr implements Action {

    public void doAction() {

        System.err.println("Yahoo");

    }

}

// [...]

doAction(new Syso());

On pourrait enfin utiliser les possibilités offertes par les enum Java :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public enum ActionEnum implements Action {

    SYSO {

        public void doAction() {

            System.out.println("Yeah");

        }

    },

    SYSERR {

        public void doAction() {

            System.err.println("Yahoo");

        }

    };

}

// [...]

doAction(ActionEnum.SYSO);

J’espère que ce court article vous aura convaincu qu’il est tout à fait possible de se passer des switch. Un code comprenant des switch et autres if () {} else if (){} est en général tout sauf simple et maintenable.
Dans Clean Code, Uncle Bob Martin conseille d’ailleurs d’encapsuler le code lié aux switch dans des fabriques abstraites, afin de ne pas les laisser polluer le reste du code.

Pouvez-vous me faire un rapport sur tous les ajouts et les modifications qui ont été faits sur la table des factures en production depuis 5 ans ?

Hibernate a vraiment pensé à tout, aujourd’hui nous allons parler de l’interface Interceptor et de son utilisation dans le but de faciliter l’audit du système d’information (ici la base de données).

L’interceptor hibernate

Cette interface fournit des méthodes qui interceptent différents événements de la session comme la suppression, l’ajout ou la modification de données.

Vous pouvez implémenter Interceptor directement, ou mieux : étendre EmptyInterceptor et n’en surcharger que les méthodes qui vous intéressent. Voici un exemple :

Attention cependant, auditer les insertions et les mises à jour peut ralentir votre application !

Pour rendre effective l’utilisation par Hibernate de votre Interceptor, passez-le en paramètre lors de la création de la session (sf correspond à la SessionFactory) :

Interceptors versus Triggers

Pour se rappeler de ce qu’est un Trigger SGBD, lire cet article !

Les triggers

Les Interceptors

Conclusion

Voilà, encore une façon supplémentaire de tracer ce que font vos utilisateurs. N’oubliez pas que les erreurs sont plus faciles à mettre sur le dos d’un autre quand il existe des preuves qui vont dans votre sens .

Pouvez-vous me faire un rapport sur tous les ajouts et les modifications qui ont été faits sur la table des factures en production depuis 5 ans ?

Mais bien sûr je n’ai qu’à faire haut haut bas bas gauche droite gauche droite b a, et le tour est joué ! Et en plus, je vous ai fait un café !

Bravo, j’ai pu démasquer des centaines de fraudes grâce à vous ! Vous êtes trop puissant Black Dynamite !

Cuz there aint no hope for dudes who deal dope!

* référence à Marina Orlova, qui m’a appris que l’etymologie pouvait être sexy.

Dans cet article, je vous propose quelque chose d’assez différent des sujets abordés habituellement. En lisant du code écrit par d’autres développeurs, je suis resté perplexe sur quelques méthodes. Après les avoir relues quelques fois, la façon d’écrire m’a fait sourire, comme quoi d’un développeur à l’autre les méthodes de réflexion et d’écriture de code varient fortement.

Je vous propose donc quelques extraits de code méritant le détour, ça donne des snippets assez drôles, cherchez l’erreur !

Continue comme ça

1
2
3
4
5
6
7
for (Object i : list) {

  if (condition) {

    doSomeStuff(someArguments);

    continue;

  }

  doSomeStuff(someOtherArguments);

}

continue, what else? (ce jeu de mots est © Pierre-Yves Ricau)

Tu peux pas test

Contexte : imaginez une méthode initialize(java.util.Properties) qui s’attend à la présence d’une propriété MY_PROPERTY pour l’utiliser lors de l’initialisation d’un objet :

1
2
3
4
5
public void initialize(Properties props) {

  if (props.getProperty(MY_PROPERTY)) {

    // ici on utilise cette propriété...

  }

}

Le test unitaire est tout naturellement :

1
2
3
4
5
6
  public void testNullProperty(){

    Properties properties = new Properties();

    assertNotNull(properties);

    assertNull("property must be null", properties.getProperty(MY_PROPERTY));

    myClassInstance.initialize(properties);

  }

Pour résumer, on teste si une instance fraichement créée est non-nulle, tout en vérifiant qu’elle ne contient pas encore la propriété… Quant à la méthode initialize() qui est censée faire l’objet du test, certes on l’appelle mais on ne fait aucune vérification dessus. Bon, après tout le test passe, c’est le principal non ?
Ce test n’est d’ailleurs pas isolé, plusieurs autres tests vérifient de la même façon la non-présence dans properties d’autres propriétés utilisées dans initialize() .

Double fail inversé

1
myVar = (myMap != null) ? "" : myMap.get(myField);

Non seulement on n’a pas la valeur attendue, mais en plus on aura forcément une NullPointerException si myMap vaut null .

True or false?

1
2
3
4
5
public boolean superComplexLogic(boolean value) {

    boolean ret= false;

    if((getValue2() && value) || (!getValue2() && !value)) ret=true;

    return ret;

}

Pourquoi faire simple ? Un return (getValue2() == value); aurait été tellement banal !

TODO != Tout doux

1
2
3
4
// TODO en lot 8

if ("TODO".equals("TODO1")) {

  // ...

}

Sympathique cette façon d’éviter que du code soit executé, non ?

100% de couverture de tests !

1
2
3
4
5
6
7
8
9
10
public enum MyEnum {

    MY_CONSTANT("O"),

    //...

}



// Et le test associé :

@Test

public void testMyConstant() {

    assertEquals("O", MyEnum.MY_CONSTANT);

}

Au moins, si on fait une faute de frappe en écrivant l’enum, ce test le verra tout de suite

L’opération a échoué avec succès !

1
2
//succes - Recuperer la liste à réemettre.

logger.logError(ServiceLogKeys.SUCCESS_CODE);

Conclusion

J’espère que ce petit moment de détente vous a plus, si c’est le cas nous allons essayer de motiver les troupes d’Excilys pour publier des articles collaboratifs de ce genre de temps en temps. Si vous avez aussi des exemples de LOLcode, n’hésitez pas à vous lacher dans les comms (attention aux clauses de non divulgation tout de même) .

Par ordre chronologique :

• février 2010 : version 6 de Liferay Portal en approche
• avril 2010 : Liferay Portal fête ses 10 ans
• mai 2010 : sortie théorique de Liferay IDE 1.0

Liferay pour la vie

Liferay Portal 6 annoncé

En février dernier, Paul Hinz a dévoilé l’information que la prochaine version serait numérotée 6 et non pas 5.3 comme nous avions pu le penser. En effet, depuis quelques temps déjà, Liferay Portal 5.2 (plus précisément 5.2.3) est la dernière version officielle. La numérotation en 5.3 était par exemple utilisée dans le Jira de Liferay pour désigner la version suivante corrigeant une anomalie. Depuis la numérotation dans Jira a bien sûr été corrigée . Ce choix vient du fait qu’après avoir revu l’ensemble des fonctionnalités et améliorations futures prévues dans la stratégie de développement du portail, il a été décidé que la release suivante profiterait d’un changement de numéro de version majeur.

Cette version avait pour nom de code Bunyan en interne et sera donc officiellement Liferay Portal 6.

L’annonce officielle postée sur le blog de Liferay mentionnait les éléments suivants comme étant majeurs et à surveiller :

Parmi ces éléments, on peut noter l’amélioration de l’intégration des workflows et pour ce faire nous devrions bénéficier du support de jBPM. Concernant la bibliothèque de documents, celle-ci devrait pouvoir s’intégrer avec Documentum, CMIS et Sharepoint par exemple.

Liferay Portal 6 va se baser sur des technologies JEE courantes et chercher à ajouter ou simplement améliorer leur prise en charge, au cœur du portail ou/et pour l’ouvrir aux systèmes externes :

• JPA et JMX seront intégrés, OAuth sera amélioré, le support de Maven devrait être presque natif
• les plugins pourront exposer des web services en JSON et SOAP
• intégration avec OpenOffice, Google Apps, Jasper, BIRT
• possibilité de changer de moteur de BPM (utiliser Intalio à la place de jBPM par exemple)
• intégration avec NetVibes, OpenSocial, SEO, CalDAV, SalesForce, Vaadin
• formulaires et listes dynamiques
• gestionnaires de tâches et de contacts

Premiers retours sur Liferay Portal 6 preview / RC

Dans un premier temps, cette version 6 n’a été mise à disposition que par l’intermédiaire d’une preview. Le site officiel n’en faisait pas mention, mais SouceForge et les Nightly Builds commençaient à diffuser ces premières ébauches à tester.

Deux mois plus tard, en avril, c’est au tour de la Release Candidate d’avoir été officialisée. Elle incluait de nombreux correctifs et la plupart des portlets finales qui manquaient dans la preview, dont la traditionnelle application de démarrage 7Cogs.

Depuis la sortie de la version RC de Liferay Portal 6, la page de téléchargement habituelle prépare les utilisateurs au changement à venir. En effet, vous pouvez toujours choisir de récupérer un bundle basé sur Liferay Portal 5.2.3 CE, mais vous pouvez également vous essayer à la RC. Une liste déroulante proposant les bundles mis à jour pointe ainsi sur la dernière version officielle de Liferay Portal 6.

La première version RC numérotée 6.0.1 semble souffrir d’un nombre important de retours d’anomalies. Ceci explique surement en partie le retard qui commence à grandir pour la release finale et aussi la longue durée depuis laquelle nous attendons la sortie de la RC2. Cette deuxième RC devrait débloquer la situation, espérons-le.

Notons quand même que la roadmap initiale prévoyait une sortie finale de Liferay Portal 6 entre février et avril 2010 pour respectivement les versions Community Edition et Enterprise Edition. Il est maintenant souhaitable que toutes ces corrections de bugs qui se sont ajoutées permettent d’obtenir un portail avec une meilleure finition comparé aux versions précédentes .

Liferay Portal a 10 ans

Le 23 avril dernier, Liferay nous a fait cadeau d’une belle newsletter intitulée ‘10 Years of Open Source: Liferay in 2010′. En effet, la société s’est construite sur son portail et a su évoluer en trouvant les partenaires de poids nécessaires. Maintenant elle continue son chemin en profitant de son expérience.

Je vous retranscris ici le contenu de leur message :

Cette année marque le 10ème anniversaire de Liferay Portal. Brian Chan a démarré le développement en 2000 et Liferay est très rapidement devenu la plateforme de premier choix pour construire des applications d’entreprises dynamiques et efficaces. Avec 3 millions de téléchargements, 250 000 déploiements et une communauté active d’environ 30 000 personnes, Liferay a connu une croissance explosive dans sa 11ème année.

Un éclat éternel ?

Cette année marque aussi le 6ème anniversaire de la société, basée sur l’open source, et Liferay célèbre plusieurs jalons :

• Des centaines de sociétés clientes comme Cisco Systems, Electronic Arts et Société Générale
• Plus de 60 partenaires dans le réseau international
• Reconnu deux ans de suite comme Visionnaire dans le Gartner’s Magic Quadrant
• Forte croissance des revenus et du support présent dans les bureaux d’Amérique du nord, d’Europe, du Brésil, d’Inde et de Chine.

Merci pour votre soutien et au plaisir de travailler à vos côtés en 2010 !

Si nous reprenons un peu l’historique, voici ce qu’on pourrait obtenir :

• 2000 : premiers développements par Brian Chan, pour proposer un portail d’entreprise pour les organismes à but non lucratif
• 2006 : création de la société Liferay Inc., et de la filiale Liferay GmbH en Allemagne
• 2007 : ouverture de nouveaux bureaux en Asie et en Espagne
• 2009 : création d’un bureau en Inde

La croissance de Liferay s’est faite aussi grâce à des partenariats :

• ICEsoft Technologies, en juillet 2007, pour incorporer la technologie Ajax
• janvier 2008 : recrutement du lead engineer de jQuery UI
• Sun Microsystems, en mai 2008, pour un accord d’échange technologique
• 2009 : Liferay intègre le comité de spécification de Oasis CMIS
• IT Mill Ltd., en octobre 2009, pour travailler autour de leur librairie de UI nommée Vaadin

Liferay IDE 1.0 en vue

Gregory Amerson a rejoint l’équipe Liferay à Los Angeles en février 2010. Son expérience de senior developer sur MyEclipse l’a propulsé au poste de software engineer en charge du développement de l’outillage autour du portail et plus spécifiquement basé sur Eclipse. La première release de Liferay IDE devait se faire suivant un plan de 2 mois aboutissant sur la publication de la version 1.0.

Le jour et la nuit

Depuis avril, le développement suit son court et les premiers builds sont testables pour les plus motivés. Six vidéos de démonstration ont été publiées et présentent certaines des fonctionnalités qui seront présentes de façon certaine dans la version finale :

1. Create new plug-in project
2. Portlet Project Deployment
3. New Portlet Wizard
4. New Hook Wizard
5. More Hook Wizard
6. Plug-in Package Editor

La date du 12 mai avait été donnée pour la sortie de la version 1.0 finale. Plus de 2 semaines plus tard, force est de constater que nous devons encore patienter un peu.

Dans les cartons de Liferay IDE

Liferay IDE 1.0 proposera la gestion du serveur Liferay Portal, la création d’un projet, des éditeurs pour les descripteurs spécifiques et des wizards de création d’artefact de portail, le tout conforme à l’état de l’art des pratiques que chaque développeur utilisant Liferay doit répéter sans cesse dans son environnement de développement personnel.

La page du wiki officiel qui présente Liferay IDE nous donne quelques éléments de détails :

Le but de Liferay IDE est de fournir l’outillage basé sur Eclipse le plus abouti qui soit pour l’environnement de développement de Liferay Portal à destination des versions 6.0 et supérieur.

Liferay IDE viendra complémenter l’existant d’une façon très similaire à ce que fait SpringSource Tool Suite pour la plateforme Spring.

Livrables produits sans aucune différence de fonctionnalité :

1. Liferay IDE All-in-one bundle (incluant par exemple un JRE, un pack Liferay, la JavaDoc, des packages complémentaires de sources du portail, etc.)
2. Liferay IDE plugins bundle pour Eclipse Galileo JEE (3.5.x)
3. Update site pour Eclipse Galileo

Priorités :

1. Pouvoir démarrer facilement sur la plateforme Liferay
2. Simplifier ou automatiser les tâches fréquentes et ennuyeuses
3. Intégrer le Liferay Plugins SDK
4. Développer, déployer et débugger les plugins Liferay facilement

Disponible entre autres pour la version 1.0 :

• Importer, créer et travailler sur des projets Eclipse de plugins Liferay directement
• Prendre en charge le Liferay Portal depuis l’IDE
• Nouveaux wizards pour automatiser les créations répétitives de contenus
• Assistance à la saisie
• Templates personnalisés

Prévu pour les versions suivantes notamment :

• Gestion avancée du Plugins SDK et du bundle Liferay Portal utilisés
• Projets pour les Theme et Layout Template
• Éditeurs améliorés et validation des structures saisies
• Gestion automatique des dépendances
• Log d’activité du serveur

Premiers retours sur Liferay IDE 1.0 preview

La communauté a fait part de son intérêt pour cet IDE qui était très attendu. Pour la version 1.0, Eclipse est la priorité absolue et donc seul ciblé. Par la suite, les autres IDE devraient pouvoir recevoir une prise en charge par le biais de plugins officiels. Un travail notable d’intégration pour NetBeans ayant déjà été entrepris (cf. Portal Pack), ce dernier devrait être géré rapidement. Quant à IntelliJ IDEA, il sera aussi supporté à l’avenir.

L’équipe reste à l’écoute des besoins des utilisateurs et par exemple, se montre intéressée lorsqu’est évoqué le “besoin” de gérer la prise en compte native de JSF 2.0 pour les portlets directement depuis l’IDE. D’autres idées émises concernent par exemple la gestion directe par l’IDE d’artefacts Maven spécifiques à Liferay pour donner suite au Liferay Maven SDK.

Pour tester la version de preview, Gregory Amerson a mis en place un update site à ajouter dans votre Eclipse :

http://gregamerson.com/liferay-ide/updates/latest/

Fin mai, seule la version 6.0.1 du portail (Liferay Portal 6 RC 1) est officiellement disponible au téléchargement depuis SourceForge. Ceci pose problème si vous tentez d’utiliser la version preview de Liferay IDE qui demande que votre portail soit au minimum en version 6.0.2. La seule solution semble donc être de se tourner vers les Nightly Builds du portail en attendant que la RC 2 soit publiée officiellement. L’url pour récupérer ces builds est :

http://releases.liferay.com/portal/nightly/

D’après Gregory Amerson, le build Liferay Portal 6 RC 2 sera publié d’ici peu et Liferay IDE 1.0 devrait suivre de près. Plus que quelques jours à attendre donc !?

Conclusion

Voici donc quelques actualités majeures dans le “petit” monde de Liferay qui méritaient qu’on s’y attarde un peu. Et puisque les sujets sont encore bien chauds, nous devrions voir arriver très rapidement les annonces des releases finales. Et encore d’autres surprises peut être ?

Pour terminer et ne faire que les mentionner, GateIn et eXo Platform sont les premiers à faire beaucoup parler d’eux ces derniers temps parmi les éditeurs de portails, donc Liferay a tout intérêt à se montrer entreprenant pour ne pas se faire distancer !

Références

• Billets de Paul Hinz : http://www.liferay.com/web/paul.hinz/blog
• Billets de Brian Chan : http://www.liferay.com/web/brian.chan/blog
• Wiki Liferay : http://www.liferay.com/community/wiki/
• Billets de Gregory Amerson : http://www.liferay.com/web/gregory.amerson/blog

Suite à la mise en place d’un environnement de développement Flex en Open Source, je vous propose aujourd’hui de simplifier l’utilisation de BlazeDS grâce à Spring BlazeDS Integration (Spring-flex).

La description suivante, traduite de l’introduction faite sur le site officiel, résume bien les buts recherchés :

Spring BlazeDS Integration est une réponse à une demande de la communauté qui souhaitait avoir une solution pour construire des RIA propulsées par Spring, utilisant Adobe Flex pour la technologie client. [...] Bien qu’il était possible d’utiliser BlazeDS pour se connecter à des services gérés par Spring, ce n’était pas réalisable de manière “naturelle” pour un développeur Spring, nécessitant d’avoir à maintenir une configuration XML BlazeDS séparée. Spring BlazeDS Integration change tout cela en transformant le MessageBroker de BlazeDS en un objet géré par Spring, ouvrant des perspectives vers une intégration plus complète qui suit le “Spring way”.

Dans cet article, nous allons voir les principes de base de Spring BlazeDS Integration : configuration, exposition des services et consommation par un client Flex. Un projet est réalisé en parallèle pour illustrer la théorie ; les exemples de code suivant en sont tirés. Le code source final est disponible à la fin de cet article. Si vous n’avez pas encore lu le précédent article, je vous invite à le faire car il explique de nombreuses notions qui seront réutilisées ici.

Mise en place de la webapp

C’est bien Mave(i)n(e)…

Une fois n’est pas coutume, nous allons utiliser Maven 2 pour créer le squelette d’application web qui sera utilisée par le client Flex :

1
mvn archetype:create -DgroupId=com.excilys.java -DartifactId=SimpleSpringFlex -DarchetypeArtifactId=maven-archetype-webapp

Retour aux sources

Ajoutons tout de suite les bonnes dépendances vers Spring-Flex :

1
2
3
4
5
<dependency>

  <groupId>org.springframework.flex</groupId>

  <artifactId>spring-flex</artifactId>

  <version>1.0.1.RELEASE</version>

</dependency>

Commençons par adapter le descripteur de déploiement web.xml :

1
2
3
4
5
6
7
8
9
10
11
12
13
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

  <display-name>Simple Flex Remoting with Spring-Flex</display-name>

  <servlet>

    <servlet-name>dispatcher</servlet-name>

    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

    <load-on-startup>1</load-on-startup>

  </servlet>



  <servlet-mapping>

    <url-pattern>/messagebroker/*</url-pattern>

    <servlet-name>dispatcher</servlet-name>

  </servlet-mapping>

</web-app>

Comme dans l’article précédent, nous mappons le pattern /messagebroker/* sur une servlet, sauf que maintenant ce n’est plus une MessageBrokerServlet, mais une DispatcherServlet Spring. Le travail de Spring va donc commencer ici. Profitons de la convention du framework qui ira chercher par défaut la configuration du conteneur Spring associée à cette servlet dans le fichier WEB-INF/dispatcher-servlet.xml :

1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:flex="http://www.springframework.org/schema/flex"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="

        http://www.springframework.org/schema/beans

        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

        http://www.springframework.org/schema/flex

        http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">



  <flex:messagebroker />

</beans>

Par rapport à une configuration classique, notez l’inclusion de l’espace de nommage “flex”, qui va rendre disponible la balise messagebroker. Celle-ci va nous permettre de créer un managed bean de type MessageBroker, qui va gérer les flux AMF (là aussi on profite de la configuration par défaut du bean, notamment pour le nom du fichier de configuration services-config.xml).

Exemple de Bean non managé par Spring

Création des services

Dans cette partie, nous allons faire du Java “classique”. Le but de la webapp créée au tout début de l’article est d’exposer des services à notre client Flex. Créons donc notre service, qui va permettre d’additioner deux nombres (calcul nécessitant de grosses ressources type cluster ) :

1
2
3
4
5
6
7
package com.excilys.java.springflex.service;



public class MathService {

    public int add(int a, int b) {

        return (int)((2*(double)a/b) * ((double)b/(int)Math.sqrt(4)) + (b << 2) / 4); // Addition standard.

    }

}

Exposition (gratuite) de services

Il nous reste maintenant à rendre ce service accessible à notre application Flex. En utilisant BlazeDS directement, il faudrait ajouter chaque service dans le fichier WEB-INF/flex/services-config.xml. Avec Spring-flex, nous allons pouvoir minimiser cette configuration :

1
2
3
4
5
6
7
8
9
10
11
12
<services-config>

  <services>

    <default-channels>

      <channel ref="my-amf"/>

    </default-channels>

  </services>

  <channels>

    <channel-definition id="my-amf">

      <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"/>

    </channel-definition>

  </channels>

</services-config>

On se contente de dire que les services utiliseront par défaut le channel “my-amf”, avec l’endpoint /mesagebroker/amf. Pour exposer notre service, nous pouvons utiliser l’annotation @RemotingDestination :

1
2
3
4
5
6
7
//...

import org.springframework.flex.remoting.RemotingDestination;



@RemotingDestination

public class MathService {

  //...

}

Pour que ces annotations soient prises en compte, il faut bien évidemment utiliser la balise component-scan dans dispatcher-servlet.xml :

1
2
3
<bean xmlns:context="http://www.springframework.org/schema/context" ...>

  <context:component-scan base-package="com.excilys.java.springflex" />

</bean>

Appels depuis le frontend Flex

Nos services sont exposés, nous pouvons maintenant les consommer depuis du code Flex. Pour cela, nous utiliserons un RemoteObject de la même manière que dans l’article précédent. Le channel “my-blazeds” utilisera l’URL du DispatcherServlet :

1
2
3
4
<channel-definition id="my-blazeds" >

  <endpoint uri="http://localhost:8080/SimpleSpringFlex/messagebroker/amf"

      class="flex.messaging.endpoints.AMFEndpoint" />

</channel-definition>

Spring-Flex en action

Et après ?

Ajouter d’autres services (soustraction, multiplication, …) consiste à ajouter des méthodes dans MathService. Pour exposer d’autres classes de services, il suffit de les annoter avec un @RemotingDestination.

Si vos services  nécessitent une authentification préalable, il est possible de sécuriser les destinations avec Spring Security.

Enfin, pour la partie messaging, Spring BlazeDS Integration facilite l’envoi de messages entre clients Flex et/ou POJOs. Il est ainsi possible d’utiliser AMF ou JMS de manière similaire, grâce à une couche d’abstraction.

Nous venons de voir qu’une fois de plus, Spring nous propose un module assez simple d’utilisation qui permet de gagner en clarté de configuration et en rapidité d’exposition de services. La configuration XML est minimisée, les annotations font le reste. Et comme c’est bien pensé, ça s’intègre sans problème avec d’autres briques Spring liées par exemple à la sécurité. C’est-y pas beau çà ?

Code source

Pour bidouiller vous-même Spring-Flex, vous pouvez télécharger le code source du projet réalisé dans cet article.

Une fois n’est pas coutume, ce deuxième mardi du mois a été l’occasion pour les Javaïstes parisiens d’assister au Paris JUG, consacré cette fois aux processus de build, share et deployment. Pas de chance, la salle était déjà bien pleine quand je (Bastien) suis arrivé… vite, une chaise tout devant !

De mon côté (Pierre-Yves), ayant posé ma tente devant la salle la veille au soir, j’ai eu accès aux premiers rangs. Allez, je vous livre un petit secret : pour avoir un placement correct au Paris Jug, il faut arriver à 19h (ou être une JDuchess ). Je (Pierre-Yves) vais donc vous parler des trois premières présentations, et je (Bastien) continuerai avec les deux dernières.

Les secrets de fabrication du W3C

Par Alexandre Bertails

Qui connaît réellement le W3C ? En dehors des outils de validation et des spécifications HTML 5, peu d’entre nous en savent plus sur cet acteur historique du Web. Alexandre Bertails nous en dit plus, dans un temps imparti relativement court.

Saviez-vous que le site web du W3C vient d’être refait à neuf, après un an et demi de travail ? Ce n’est pas juste une CSS, le contenu et l’arborescence ont été revus, sans cependant casser aucun lien. Allez-y, visitez-le (bien plus joli qu’en 2008, 2002 et même 1996).

J’ai aussi découvert que le W3C est composé à 40% de français. Que les outils avec lesquels travaillaient les salariés n’étaient pas forcément orientés Web, mais que les choses ont bien évolué récemment.

On regrettera le flux permanent des retardataires (ça va, je (Bastien) le saurai pour la prochaine fois !), qui ont quelque peu perturbé notre attention à tous, sans toutefois départir Alexandre de ses moyens (et c’est tout à son honneur !).

DVCS

Par Sébastien Douche

Speaker hors pair, Sébastien Douche nous a donné envie de nous jeter à l’eau (pardon… facile celle-là) et de nous mettre immédiatement aux DVCS (Distributed Version Control System, système de gestion de versions distribué).

Auparavant, lorsqu’il intégrait un nouveau groupe de travail, Sébastien avait l’habitude d’y déployer sa boîte à outil habituelle : SVN, et Trac. Jusqu’au jour où il s’est retrouvé chef de projet sur un projet from scratch.

J’aime beaucoup la métaphore qu’il nous a donné : la maintenance d’une application, c’est du ski sur pistes, il y a des dizaines de développeurs qui sont passés avant toi et qui ont tracé la piste. Le développement à partir de zéro, c’est du ski hors piste, tu sais la direction que tu veux prendre, mais tu es en haut de la montagne, ya du brouillard, il faut se lancer, et tu n’as pas de repères immédiats.

Avec le temps, le projet, pourtant “agile”, a eu de plus en plus de mal à livrer dans les temps, et la qualité de travail s’est progressivement dégradée. Pourquoi ? Parce que les développeurs passaient leur temps à faire des micro-commit/micro-merge et à intégrer le travail des autres, au lieu de pouvoir se consacrer au développement des fonctionnalités.

C’est une sale habitude que nous donne SVN : merger le code est vécu comme une expérience difficile. On préfère donc commiter le plus vite possible pour que ce soient les autres développeurs qui aient à merger. Les micro-commit sont aussi bien moins difficiles à merger. Quand aux branches SVN, elles sont aussi faciles à créer que complexes à merger…

SVN ne sert plus au final qu’à faire de l’historisation, c’est un super “Annuler / Répéter”.

Les DVCS récents permettent à chaque développeur de travailler en local (fonctions d’historisation) et en isolation, et de pousser le code sur un repository central uniquement lorsque la fonctionnalité est terminée. Leur grande force est la flexibilité qu’ils introduisent, permettant à chacun de bosser comme il l’entend tout en respectant les règles d’organisation du groupe.

Il est aujourd’hui possible de passer à un DVCS en douceur, sur son poste de travail, en important un repository SVN qui peut rester le repository principal, mais en disposant des avantages d’un Git ou d’un Mercurial en local.

Sébastien en a aussi profité pour nous présenter la manière dont travaille son équipe : le repository central comporte uniquement du code “livrable” (au sens livraison de fin de Sprint). Chaque fois qu’une fonctionnalité a été codée par un développeur, une revue de code est réalisée par un autre développeur, une démo est réalisée, et si tout va bien alors seulement les modifications sont poussées sur le repository central.

Sa conclusion : si vous ne devez apprendre qu’une techno en 2010, ce n’est pas Scala, JEE 6, Maven 3… apprenez à utiliser un DVCS !

Git

Par David Gageot

Plutôt que de faire de sa présentation un énième tutoriel sur Git et tous les concepts associés, David Gageot a préféré nous montrer la puissance de Git en quelques exemple pratiques.

Tout d’abord, git bisect. Cette fonctionnalité permet d’automatiser la recherche du commit qui a créé une régression. Le fonctionnement est simple : on fournit à Git un script permettant de déterminer, pour une version donnée, si le bug est présent ou non. git bisect va ensuite réaliser une recherche dichotomique entre deux numéros de versions, et identifier très rapidement le commit coupable.

Cette fonctionnalité n’a pas grand chose à voir avec le fait que Git soit un DVCS (distribué), mais reste un argument de poids pour adopter cet outil. C’est aussi possible grâce à la rapidité avec laquelle un Git ou un Mercurial peuvent réaliser un checkout ou changer de version sur une copie locale.

David nous a ensuite montré un script qu’il a réalisé, qui permet de conditionner automatiquement le push vers le repository au fait que le build et les tests passent. Il peut donc tranquillement bosser et commiter pendant qu’en tâche de fond le build et les tests sont exécutés, et ainsi se passer d’un Hudson.

La présentation s’est terminée par des démonstration sur l’évolution de dépôts Git à l’aide de Gource, qui permet de représenter dans le temps les modifications effectuées sur un dépôt de sources, et le travail de chacun.

Le Gource du projet Linux

En conclusion, quelques conseils :

• testez Git le plus vite possible,
• n’essayez pas de faire du SVN avec Git, il faut oublier comment SVN fonctionne, désapprendre les mauvais réflexes,
• un bon moyen pour démarrer, c’est de jouer avec github,
• n’hésitez pas à utiliser Git dans le cadre de vos projets, au moins en local, il vous apportera une forte plus value même si votre équipe continue d’utiliser SVN.

Pause Buffet

Le buffet était gracieusement offert par Nicolas Martignole, suite à un défi lancé sur Twitter. Il en a profité pour faire de la pub pour l’eXpress Board, un job board pour les passionés. J’ai (Pierre-Yves) aussi pu croiser Emmanuel Bernard, apprenant ainsi que si l’équipe Hibernate n’utilise pas de DVCS pour le moment, ils songent à y passer, notamment pour faciliter l’intégration de contributions externes.

Build it with Maven 3!

Par Nicolas de Loof & Arnaud Héritier

Invités surprise, Fred et Jamy nous ont montré que Maven, c’est pas sorcier ! Certains se souviennent encore des migrations longues et périlleuses des Makefile vers Ant, puis vers Maven 1 et Maven 2. Cette fois, les développeurs du célèbre gestionnaire de build ont voulu éviter cela : la compatibilité de Maven 3 avec des projets en version 2 est en théorie de 99.99% (hormis maven site qui n’est pas encore au point).

Première rencontre avec Maven 3

Les mots-clé de la première release stable seront donc les suivants :

• compatibilité : en prenant n’importe quel projet Maven 2, sans aucune modification on pourra le builder avec Maven 3,
• modularité/extensibilité : le socle de l’application a été entièrement repensé (en évitant les problèmes de rigidité et de complexité de la version 2). Au menu, utilisation de Java 5, apparition d’APIs simples et intuitives, de la doc… Bref, de quoi faire des plugins sans se prendre la tête,
• Mercury : ce système voué à remplacer le mécanisme d’artifacts… a finalement été abandonné .

Maven 3 introduit la notion de build plan, qui permet de savoir à l’avance toutes les actions qui vont être effectuées dans un build (une sorte de contexte d’exécution). Ainsi, un plugin sera au courant de ce que feront les autres, donnant la possibilité d’avoir des builds intelligents (où les tests ne seront pas lancés deux fois par deux plugins différents par exemple).

Au niveau des descripteurs de build, la structure des pom.xml a été améliorée et Maven 3 devient polyglotte. On peut à présent écrire des descripteurs en groovy ou en python par exemple. Les exclusions globales de dépendances sont maintenant possibles (on va enfin pouvoir se débarrasser de cette *$#~ de dépendance sur un logger qui plante toujours… ).

Toujours dans les descripteurs, la notion de mixins est apparue :

Essentially it will be a POM consisting of plugins and configurations that can be externally parameterized. These mixins will be deployed to a repository and be referenced with a standard coordinate. Basically it will be an intelligent import with validation which will allow composition in your POMs.

On va pouvoir décomposer notre POM en différents morceaux, un peu à la manière des web-fragments.

Les builds parallèles vont bientôt faire leur apparition, pour ne pas que vos 7 autres cores s’ennuient (edit: Mathieu nous signale en commentaire que les builds parallèles sont déjà disponibles depuis la version 3.0-beta-1). Cette fonctionnalité sera très intéressante sur les serveurs d’intégration continue utilisant un modèle maitre/esclave (Hudson, pour ne citer que lui). Techniquement, le processus de build sera découpé en différentes phases qui se rejoindront en des points de synchronisation.

Mais au final, qu’apporte Maven 3 par rapport à Maven 2 à l’heure actuelle ? Rien, enfin presque :

• un shell (avec des jolies couleurs !) permet de faciliter les builds (notamment sous Windows),
• un gain de rapidité lors des builds.

Comme la migration de M2 vers M3 est très simple et rapide, nos deux speakers encouragent vivement les développeurs à tester Maven 3 chez eux, ne serait-ce que pour les gains en terme de rapidité de build. A vos pom, donc !

Deploy it with… DeployIt!

Par Guillaume Bodet & Benoit Moussaud

Guillaume et Benoit nous ont présenté les fondamentaux du bébé développé par XebiaLabs, DeployIt. Cet outil part du constat qu’un déploiement ne consiste pas en une simple copie d’EAR/WAR. Il y a généralement d’autres éléments à configurer (DataSources, JMS), des scripts SQL à lancer, des batches à mettre en place, etc.

DeployIt permet de gérer toutes ces étapes de manière intelligente et de faciliter l’installation d’une application. Il est repose sur trois briques principales :

• le cœur,
• des interfaces (Flex, console, Maven, Eclipse, dashboards…),
• des plugins permettant le support de JBoss, Apache, .NET etc.

La préparation d’une installation se fait en deux étapes. Dans un premier temps, on configure le Configuration Item Repository (CIR), qui est un référentiel d’informations sur les différents environnements de déploiement (test, performances, etc.). Ensuite, l’ensemble des opérations à effectuer est décrite dans des runbooks : déploiement d’un EAR, configuration d’une DataSource, installation d’un script SQL…

A partir de ces deux sources d’information, l’Intelligent Runbook Resolution Engine va se charger d’interroger les différents runbooks pour constituer un scénario de déploiement, en se basant sur les caractéristiques de l’environnement décrites dans le CIR.

Un des aspects intéressants dans DeployIt est sa faible intrusion :

• Il est agent-less, et va utiliser les moyens existants tels que ssh, sftp, scp.
• Il utilise les interfaces natives lorsqu’elles sont disponibles (wsadmin, JDBC…).
• Un plugin Maven permet de lancer les déploiements au sein d’un processus de build (au sens Maven) déjà existant dans le projet.

Seul bémol : DeployIt est un outil commercial, il existe une version gratuite mais qui n’intègre aucune notion de sécurité… XebiaLabs a ainsi la volonté de permettre aux gens de tester ce produit chez eux, tout en empêchant la possibilité de l’utiliser pour faire de vrais déploiements en production (sauf si vous êtes kamikaze).

Cependant, XebiaLabs songe à relâcher son outil en Open-Source. La majorité absolue des personnes présentes dans la salle a d’ailleurs voté positivement pour une telle action, en réponse à un sondage improvisé d’Antonio .

Conclusion

Ce Paris JUG fût riche en enseignements et en conférences de qualité. D’autres compte rendus ont été publiés sur le web : sur le blog du Touilleur Express, et sur le blog des JDuchess.

Le prochain Paris JUG aura lieu le 8 juin, avec une invitée à l’honneur : Holly Cummins.

Propos liminaire

Cet article traite de la cassification d’une application Grails. Ce néologisme pas très catholique, plus souvent employé dans la langue Shakespearienne, est synonyme d’intégration d’une application avec le système d’authentification centralisée Open Source le plus stylé au monde, j’ai nommé : CAS.

CAS, mais pourquoi faire ?

Nota : si vous connaissez déjà bien CAS et que seule l’intégration avec Grails vous intéresse, vous pouvez passer à la partie suivante, je ne vous en voudrai pas .

CAS est un système d’authentification qui permet d’authentifier des utilisateurs de manière sécurisée. La quasi-totalité des applications d’un système d’information nécessitent une authentification des utilisateurs.

Sans système d’authentification centralisé, chaque application se retrouve à développer ses propres pages de login, et gère l’authentification à sa sauce. Pour éviter d’avoir à créer/gérer / stocker les informations d’authentification dans chacune des applications, la solution consiste bien souvent à créer un référentiel commun, par exemple un LDAP, un Active Directory, ou encore une base de données commune.

Cette approche est alléchante, mais présente plusieurs problèmes :

• les développements ne sont pas factorisés, il faut redévelopper les pages de login / la mécanique d’accès au référentiel commun pour chaque webapp,
• la mécanique d’authentification n’est pas unifiée, les designs sont différents, et les utilisateurs peuvent être rapidement perdus,
• la sécurité de l’ensemble du SI repose sur la sécurité de chacune des webapp. Chaque webapp a potentiellement accès aux informations d’authentification de tous les utilisateurs. Il suffit d’une faille à un endroit pour que tout le système soit compromis.
• Les utilisateurs doivent s’authentifier sur chacune des applications web.
• De même, ils doivent se déconnecter manuellement sur chacune des applications.

CAS répond parfaitement à ces problématiques :

• Lorsqu’ils doivent s’authentifier sur une application, les utilisateurs sont automatiquement redirigés vers CAS. Il n’y a donc un seul point d’entrée pour l’authentification.
• Les utilisateurs ne sont pas perdus, ils reconnaissent la page de login CAS, et savent aussi immédiatement identifier s’ils sont sur la “vraie” page d’authentification étant donné que l’url est unique (moins de risques de phishing).
• Seul CAS a accès aux informations d’authentification. De part son caractère Open Source, sa maturité, et sa large adoption, CAS est nettement moins exposé à de potentielles failles de sécurité que vos applications développées en interne. Oui, vos applications contiennent des failles de sécurité. De part la nature du développement logiciel et sa complexité, il n’y a aucune raison pour que vous soyez mystérieusement épargné.
• CAS bénéficie d’un fort soutient de la communauté, et s’intègre avec de très nombreuses solutions. Il y a de fortes chances pour que les développements pour intégrer CAS à vos webapps soient réduits au minimum. Les nombreuses possibilités d’intégration de CAS peuvent être résumées par cette simple citation littéraire :
  

  Tu pars du Nord Ouest pour arriver au Sud Est, sans toucher la Corse ! Et tu CAS, et tu CAS !

• CAS permet d’activer le SSO (Single Sign-On, aka Authentification Unique) : l’utilisateur s’authentifie une fois, puis peut avoir accès à l’ensemble des applications du SI sans jamais rentrer de nouveaux ses informations d’authentification.
• Mieux, CAS gère le Single Sign-Out. Il est ainsi possible pour un utilisateur de se déconnecter de l’ensemble des applications en une seule action.
• Enfin, CAS permet aussi la délégation d’authentification, par exemple pour permettre à une application d’utiliser votre identité pour contacter les web services d’une autre application. Je n’en parlerai pas dans cet article, mais peut-être ultérieurement, c’est un sujet passionnant.

Ya quoi sous la carCASse ?

Sans trop entrer dans les détails du protocole CAS, en voici les principes généraux :

• Lorsque l’utilisateur s’authentifie auprès de CAS, il obtient un TGT (Ticket Granting Ticket). Ce ticket n’est jamais présenté aux applications, il permet à CAS d’identifier l’utilisateur.
• Lorsque l’utilisateur souhaite utiliser un service (une application), il demande à CAS un ST (Service Ticket) pour le service donné, en fournissant son TGT ainsi que le nom du service.
• L’utilisateur présente ensuite son ST à l’application. Celle-ci contacte CAS en lui fournissant le ST et son nom de service. CAS retourne l’identité de l’utilisateur.
• Dès lors, l’application peut placer l’identité de l’utilisateur dans la session qu’elle maintient avec celui-ci.
• Afin d’être compatible avec une utilisation web, ce protocole se traduit en pratique par un stockage du TGT dans un cookie accessible uniquement à CAS, et l’utilisation de redirections HTTP avec des URL du type “/cas/login?service=nomService” pour demander un ST et “/myapp/login?ST=leTicket” pour authentifier l’utilisateur au sein d’une application.

Notez qu’on trouve des ressemblances avec le protocole Kerberos, à ceci prêt que les tickets ne contiennent pas directement l’identité de l’utilisateur.

Et le Single Sign-out ?

• En pratique, le nom du service est l’URL vers laquelle l’utilisateur va être redirigé une fois que CAS a généré un ST. CAS maintient en mémoire la liste des URL pour lesquelles l’utilisateur a demandé un ST.
• Lorsque l’utilisateur demande à se déconnecter, CAS envoie une requête POST d’un format particulier à chacune de ces URL. Charge ensuite à chaque application de supprimer la session correspondante.
• En JEE, cela se traduit par la mise en place d’un servlet filter et d’un listener spécifiques sur chaque application.

Installer CAS sans être CASse-cou

Avant toute chose, il nous faut un CAS. On pourrait se créer un WAR aux petits oignons, en suivant cette procédure. Poil dans la main oblige, on va plutôt le télécharger directement : cas-server-webapp-3.4.2.war. Cette version de CAS a une petite particularité : pour se connecter, il suffit d’entrer un mot de passe identique au login, quelque soit le login.

Déployez le WAR dans un Tomcat, et testez : http://localhost:8181/cas-server-webapp-3.4.2/login. Pourquoi le port 8181 ? Parce qu’on va réserver le 8080 pour le jetty lancé par Grails .

Login sur CAS

Notez que le Single Sign-On ne sera disponible qu’à la condition que vous configuriez le SSL.

CAS toi, pauvre Con..tact !

Je vous propose maintenant de CASsifier une application Grails existante : ZenContact, présentée au cours d’un article précédent.

Vous n’êtes pas sans savoir que Grails, c’est du Spring MVC déguisé (vous aussi, créez votre framework web au dessus de Spring MVC). On peut donc utiliser Spring Security, qui s’intègre bien avec CAS.

Et ça tombe bien, il existe un plugin Grails qui va nous simplifier le travail : le Spring Security Plugin. Le blog Xebia en a d’ailleurs parlé dans un article plutôt complet.

Installez le plugin Acegi :

1
grails install-plugin acegi

Créez les entités pour la sécurité (utilisateurs, rôles, et mapping des url sécurisées) :

1
2
3
4
grails create-auth-domains

   com.excilys.blog.zencontact.User

   com.excilys.blog.zencontact.Role

   com.excilys.blog.zencontact.RequestMap

Je vous propose de créer les utilisateurs, les rôles et les urls protégées dans la base de données mémoire au démarrage de l’application. Il suffit de modifier le fichier $PROJECT_HOME/grails-app/conf/BootStrap.groovy et d’y ajouter le snippet suivant :

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
import com.excilys.blog.zencontact.User

import com.excilys.blog.zencontact.Role

import com.excilys.blog.zencontact.RequestMap



// [...]



def roleUser = new Role(authority: 'ROLE_USER', description: 'Utilisateur')

roleUser.save()



def roleContact = new Role(authority: 'ROLE_CONTACT', description: 'Accès aux contacts')

roleContact.save()



def user1 = new User(username: 'piwai', passwd:'NOT_USED', userRealName: 'Piwaï',

    enabled: true, email: 'ano@nymous.com')

user1.addToAuthorities(roleUser)

user1.addToAuthorities(roleContact)

user1.save()



def user2 = new User(username: 'pyricau', passwd:'NOT_USED', userRealName: 'Pierre-Yves Ricau',

    enabled: true, email: 'ano@nymous.com')



user2.addToAuthorities(roleUser)

user2.save()



new RequestMap(url: '/contact/**', configAttribute: 'ROLE_CONTACT').save()

Passons aux choses sérieuses, la configuration du plugin pour utiliser CAS. Modifiez le fichier $PROJECT_HOME/grails-app/conf/SecurityConfig.groovy, et ajoutez-y la conf suivante :

1
2
3
4
5
6
useCAS = true

cas.localhostSecure = false

cas.fullServiceURL = 'http://localhost:8181/cas-server-webapp-3.4.2'

cas.fullLoginURL = "$cas.fullServiceURL/login"

cas.failureURL = '/login/denied'

afterLogoutUrl = '/logout/afterLogout'

Et oui, c’est aussi simple que cela ! La propriété afterLogoutUrl indique la page à afficher une fois que l’utilisateur s’est déconnecté. Il faut donc créer l’action correspondante dans le LogoutController ($PROJECT_HOME/grails-app/controllers/LogoutController.groovy) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class LogoutController {



  def authenticateService;



  /**

   * Index action. Redirects to the Spring security logout uri.

   */

  def index = {

    redirect(uri: '/j_spring_security_logout')

  }



  def afterLogout = {

    def backFromCasLogoutUrl = grailsApplication.config.grails.serverURL



    def conf = authenticateService.securityConfig.security



    def casLogoutUrl = "$conf.cas.fullServiceURL/logout?url=$backFromCasLogoutUrl"



    [casLogoutUrl:casLogoutUrl]

  }

}

Ainsi que la vue associée ($PROJECT_HOME/grails-app/view/logout/afterLogout.gsp) :

1
2
3
4
5
6
<meta name='layout' content='main' />

<title>Déconnexion</title>

<div class='body'>

Vous êtes désormais déconnecté de Zencontact.<br />

Pour vous déconnecter du système d'authentification central, <a href="${casLogoutUrl}" >cliquez ici</a>.

</div>

Logout de ZenContact

Il ne reste plus qu’à exécuter l’application (grails run-app), puis accéder à une page sécurisée. Et vous pouvez même vous déconnecter ! Pour en savoir plus, consultez la configuration du plugin Spring Security.

Bonux : Single Sign-Out sans se décarCASser

Et pour terminer en beauté, on aimerait être automatiquement déconnecté de ZenContact quand on se déconnecte de CAS. C’est très pratique pour se déconnecter instantanément de toutes les applications du système d’information.

En pratique, il s’agit simplement de modifier le web.xml pour y ajouter les listeners et servlet filters et qui vont bien. Cependant, vous aurez beau chercher, vous ne trouverez pas de web.xml dans les sources de votre application. Diantre, il est généré !

La technique la plus simple est encore de modifier le template qui sert à générer le web.xml, en exécutant grails install-templates et en modifiant le fichier $PROJECT_HOME/src/templates/war/web.xml :

1
2
3
4
5
6
7
8
9
10
11
12
13
<filter>

  <filter-name>signOutFilter</filter-name>

  <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>

</filter>

<!-- ... -->

<filter-mapping>

  <filter-name>signOutFilter</filter-name>

  <url-pattern>/*</url-pattern>

</filter-mapping>

<!-- ... -->

<listener>

  <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>

</listener>

Notez enfin que le Single Sign-Out dépend du Single Sign-On, qui nécessite la mise en place du SSL.

Conclusion

Comme d’habitude, les sources sont disponibles sur le SVN du Google Code :

https://excilys.googlecode.com/svn/projects/ymca/tags/grails_cas/

J’espère vous avoir convaincu de la facilité à intégrer une application Grails à CAS, voir même vous avoir incité à découvrir CAS plus en profondeur, si ce n’était pas déjà le cas.

Et j’espère que vous ne me tiendrez pas trop rigueur de mes jeux de mots capilotractés .

Dans cet article, nous allons voir comment mettre en œuvre le design pattern Proxy en PHP pour faire par exemple de l’AOP. Nous ne couvrirons qu’une petite partie du vaste domaine qu’est la programmation par aspects, pour des raisons de simplicité et de longueur d’article.

Commençons par la classique citation Wikipedia :

La programmation orientée aspect (POA, en anglais aspect-oriented programming – AOP) est un paradigme de programmation qui permet de séparer les considérations techniques (aspect en anglais) des descriptions métier dans une application

L’utilisation de l’AOP permet ainsi de factoriser du code transverse tel que le logging des paramètres passés à une méthode, ou encore l’exécution d’une méthode au sein d’une transaction. On peut ainsi se concentrer sur le code métier dans la méthode.

Nous allons mettre en œuvre une implémentation basique d’AOP en PHP. Je sais, le domaine d’expertise d’Excilys est bien le Java .

Architecture

Le but de cet exemple est d’être le moins intrusif possible. Dans le meilleur des cas, il faudrait que l’on puisse exécuter le code avec ou sans AOP sans avoir à le modifier. Comme je suis d’humeur flemmarde aujourd’hui (oui, c’est dimanche), je vais quand même être un peu plus souple sur cette règle. Nous allons faire en sorte de pouvoir utiliser ou non l’AOP en modifiant une seule ligne de code (l’instanciation de la classe). Bien sûr, dans une vraie application l’injection de dépendances ferait que je n’aurais même pas eu à écrire ce paragraphe.

Définissons quelques termes qui seront utilisés par la suite :

• Un pointcut est un endroit dans le code où nous allons utiliser l’AOP pour ajouter un comportement (par exemple l’entrée dans une méthode). Notez toutefois que l’AOP permet dans certains cas de remplacer le comportement d’une méthode.
• Un advice est le comportement qui sera ajouté à un pointcut (par exemple afficher le nom de la méthode appelée).
• Un aspect est la combinaison d’un ou plusieurs pointcut(s) et advice(s) (afficher le nom de la méthode appelée lorsque l’on entre dedans).

Pour rester simple, nos pointcuts pourront être placés au début ou à la fin d’une méthode (et pas autour, par exemple). Ils contiendront l’advice, qui sera en fait un callback (donc une fonction ou une méthode de classe). Chaque pointcut pourra être associé à une ou plusieurs méthodes, et sera défini par :

• un nom de méthode exact,
• un joker ‘*’ pour « n’importe quelle méthode »,
• ou une expression régulière , par exemple « findAll.* »

Pour pouvoir prendre en compte ces pointcuts et appeler les advices au moment voulu, nous allons proxifier l’instance sous AOPéïne, et tout bonnement intercepter tous les appels à ses méthodes. Pour cela, rien de tel qu’une bonne vieille composition. Notre classe Proxy va contenir l’instance dans un attribut, et chaque appel de méthode sera détecté grâce à la méthode magique __call(). Elle est exécutée à chaque fois que l’on tente d’appeler une méthode non définie dans une classe (souvenez-vous, PHP est un langage dynamique ).

Comme Proxy ne définit (presque) aucune méthode particulière, tous les appels passeront par __call(), ce qui nous permettra d’exécuter les advices puis la « vraie » méthode proxifiée.

Implémentation

Passons maintenant au code. Voici la classe Pointcut :

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
54
55
56
57
<?php



namespace Pikwyx;



/**

 * A Pointcut is a place in a method where behavior will be added.

 *

 * @author bastien

 */

class Pointcut {

    const BEFORE = 1;

    const AFTER = 2;



    /** The location of this Pointcut: at the begining or at the end of a method */

    private $when;

    /** The behavior to add to the method */

    private $callback;

    /** The method name or pattern to which the Pointcut is applied */

    private $functionPattern;

    /** A flag indicating if $functionPattern is indeed a pattern */

    private $isRegexp;



    function __construct($when, $functionPattern, $callback) {

        $this->when = $when;

        $this->functionPattern = $functionPattern;

        $this->callback = $callback;



        $this->isRegexp = !preg_match('/\w+/', $functionPattern);

    }



    /**

     * Determines if the current Pointcut should be used for the given function.

     *

     * @param string $functionName the function which is called

     * @return boolean true if this Pointcut matches the function name, false otherwise

     */

    public function matches($functionName) {

        if ($this->isRegexp) {

            if ($this->functionPattern === '*') {

                return true;

            } else {

                return preg_match($this->functionPattern, $functionName);

            }

        } else {

            return $functionName === $this->functionPattern;

        }

    }



    public function getWhen() {

        return $this->when;

    }



    public function getCallback() {

        return $this->callback;

    }

}

?>

Pour nous faciliter la vie, la méthode matches a été ajoutée pour déterminer si le Pointcut courant doit être utilisé pour la méthode en cours d’appel.

Voici à quoi ressemble la seconde classe, Proxy :

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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
<?php



namespace Pikwyx;



require_once 'Pointcut.php';



/**

 * A class which wraps an instance of any class and allows to add behavior

 * before or after calling methods on this instance.

 *

 * @author bastien

 */

class Proxy {



    /** The instance on which we want to add behavior */

    private $proxifiedClass;

    /** An array of pointcuts to be placed before method calls */

    private $beforePointcuts = array();

    /** An array of pointcuts to be placed after method calls */

    private $afterPointcuts = array();



    function __construct($proxifiedClass) {

        $this->proxifiedClass = $proxifiedClass;

    }



    /**

     * Allows to add logic before a method is called on the instance.

     *

     * @param string $functionName the method on which to add behavior

     * @param callback $callback the behavior to add

     */

    public function doBefore($functionName, $callback) {

        $pointcut = new Pointcut(Pointcut::BEFORE, $functionName, $callback);

        $this->beforePointcuts[] = $pointcut;

    }



    /**

     * Allows to add logic after a method is called on the instance.

     *

     * @param string $functionName the method on which to add behavior

     * @param callback $callback the behavior to add

     */

    public function doAfter($functionName, $callback) {

        $pointcut = new Pointcut(Pointcut::AFTER, $functionName, $callback);

        $this->afterPointcuts[] = $pointcut;

    }



    /**

     * Magic function that intercepts any call to methods to allow advices to

     * be called.

     *

     * @param string $name the method name

     * @param mixed $arguments arguments to pass to the method

     */

    public function __call($name, $arguments) {

        $this->runAdvices($this->beforePointcuts, $name);



        if (is_array($arguments)) {

            call_user_func_array(array($this->proxifiedClass, $name), $arguments);

        } else {

            call_user_func(array($this->proxifiedClass, $name), $arguments);

        }



        $this->runAdvices($this->afterPointcuts, $name);

    }



    /**

     * Run the advices contained in the given list of pointcuts if they match

     * the given method name.

     *

     * @param array $pointcuts a list of Pointcut to match to the method

     * @param string $methodName the method which is called on the proxified class

     */

    private function runAdvices($pointcuts, $methodName) {

        foreach ($pointcuts as $pointcut) {

            /* @var $pointcut Pointcut */

            if ($pointcut->matches($methodName)) {

                call_user_func($pointcut->getCallback());

            }

        }

    }

}

?>

Les méthodes doBefore() et doAfter() permettent d’ajouter des pointcuts avant ou après une méthode de la classe proxifiée. Par la suite, lors de chaque appel, __call() sera exécutée, et utilisera ces pointcuts avant et après avoir appelé la méthode proxifiée.

Nous utilisons massivement call_user_func ^[1], qui est une fonction native de PHP permettant d’appeler une méthode par son nom contenu dans une chaine de caractères. Nous utilisons son premier argument sous forme de tableau, contenant également la référence vers l’objet sur lequel la méthode sera appelée.

Le « main » ressemblera donc à ceci :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php



require_once 'Pikwyx/Proxy.php';

require_once 'Foo.php';

require_once 'FooAdvice.php';



use Pikwyx\Proxy;



$foo = new Proxy(new Foo);

$fooAdvice = new FooAdvice();

$foo->doBefore('doSomeStuff', array($fooAdvice, 'onBefore'));

$foo->doAfter('doSomeStuff', array($fooAdvice, 'onAfter'));



$foo->doSomeStuff('AOP');

Avec :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Foo {

    public function doSomeStuff($param) {

        echo "Hey, I'm doing some stuff with $param<br/>";

    }

}



class FooAdvice {

    public function onBefore() {

        echo "I'm just before the method call!<br/>";

    }



    public function onAfter() {

        echo "I'm just after the method call!<br/>";

    }

}

On a ainsi ajouté deux pointcuts de « logging », avant et après doSomeStuff(). Le résultat produit par ce script est sans surprise :

1
2
3
I'm just before the method call!

Hey, I'm doing some stuff with AOP

I'm just after the method call!

Pour ne plus utiliser l’AOP, il suffit de remplacer $foo = new Proxy(new Foo); par $foo = new Foo;.

Et après ?

Pour aller plus loin et écrire encore moins de code, il serait possible d’apporter les améliorations suivantes :

• Ajouter un pointcut entourant l’appel à une méthode, permettant par exemple de faire un try/catch.
• Configuration des pointcuts dans un fichier XML (validé par une XSD), et récupération de l’instance du Proxy via une factory qui va se charger de lire la configuration et d’instancier automatiquement les Pointcuts.
• Utiliser un framework d’injection de dépendances pour ne pas avoir à changer une ligne de code pour activer ou non l’AOP .
• Faire en sorte que la classe proxifiée puisse être reconnue comme étant une instance de Foo et non de Proxy (dans le cas où l’objet est passé à une méthode ayant des paramètres typés). C’est LE problème majeur de cette implémentation.
• Intégrer les advices directement dans le code dans une version en cache de la classe Foo (ce qui pourrait corriger le point précédent), et mettre en place un autoloader qui permettra de créer/mettre à jour la version cachée si besoin, ou sinon de la renvoyer directement. On s’approcherait ainsi du bytecode weaving d’AspectJ.

Conclusion

Avec deux classes nous avons réussi à faire une ébauche d’AOP en PHP, ne nécessitant que peu de modifications dans du code existant. Même si l’approche est assez maladroite sur certains points (notamment le fait que l’instance de Proxy ne soit pas reconnue comme étant un objet de type Foo), avec quelques développements supplémentaires il serait possible d’obtenir des résultats rapidement intéressants. Reste à savoir si l’AOP est réellement utile dans une application PHP.

^[1] : non, cette fonction ne permet pas de téléphoner à l’utilisateur nommé “func”…

Code source