insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 4 février 2010

Le Paris JUG a 2 ans !

juggyannif02

Le Paris JUG fêtera son 2ème anniversaire mardi 9 février. Pour célébrer l'événement, l'équipe organise une soirée spéciale consacrée à l'Open-Source en France. Sacha Labourey, ancien CTO de JBoss fera la keynote. Jean-Michel Doudoux sera également présent afin de nous présenter les différentes licences permettant la diffusion libre de documentations.

Les inscriptions sont ouvertes, rendez-vous mardi au 108 boulevard Malesherbes !

Sfeir est sponsor de l'événement : c'est également l'occasion de venir nous rencontrer pendant la pause-buffet !

mercredi 2 décembre 2009

Le Motorola Droid (Milestone) débarque en France

Ce soir, j'ai pu assister à la soirée de présentation officielle du tout nouveau Motorola Droid (nommé Milestone en Europe), à l'occasion de sa commercialisation en France, et ce, dès ce soir.

Ce smartphone est un des plus attendus parmi les andro-phones : beaucoup y voient (espèrent) le tant attendu iphone killer. Pour preuve de sa popularité, à sa sortie aux états-unis (le 6 novembre), 250 000 exemplaires ont été vendus la première semaine...
Autre facteur faisant que ce téléphone attire l'attention (et pas des moindres) : il s'agit du premier téléphone équipé de Android 2.0.

Trêve de teasing, passons aux faits !

La présentation est lancée par Jacques Rames, président de Motorola France, qui nous annonce que :

  • Motorola a fait le choix d'Android en 2008, pour simplifier le développement multi-plateformes en interne et pour la facilité de déploiement d'applications (comparé à l'App Store d'Apple bien entendu).
  • Le Milestone est le deuxième téléphone Android de la marque et le début d'une longue série : Motorola projète de sortir pas moins de 10 smartphones Android en 2010, et souhaite devenir leader dans le domaine des smartphones (comme beaucoup me direz-vous).
Suite à cela, rueducommerce, qui sera - pour au moins les quelques semaines à venir - le vendeur exclusif du Motorola Milestone en France, nous annonce les tarifs :
  • à partir de 89 euros avec un forfait chez Bouygues Telecom ou SFR
  • beaucoup plus cher chez Virgin Mobile ou Orange (à partir de 189 euros et 219 euros !)
  • 549 euros le téléphone nu, sans abonnement
  Pour ceux qui le souhaitent, vous pouvez dès maintenant réserver ce téléphone en pré-commande chez rueducommerce. On nous a annoncé le début des livraisons mi-décembre (pour que tout le monde puisse avoir un joli Milestone sous son sapin de Noël ;)
Soit dit en passant, et ça aussi c'est Noël, jusqu'à fin décembre, pour le même prix, rueducommerce offre 60 euros d'accessoires en plus : un support multimédia (pour servir de mini-chaine hi-fi), et un support voiture (pour servir de GPS). Voir photo ci-contre.


Bien, l'aspect marketing et commercial étant passé, passons au côté technique !
Alors, qu'a t-il dans le ventre ce fameux Milestone ? Voici ses principales caractéristiques :
  • un écran très grand de 3,7 pouces (tout en restant compact)
  • le support du multi-touch
  • un processeur puissant cortex A8
  • une mémoire vive conséquente de 256 Mo (comme l'iphone 3GS)
  • un clavier physique AZERTY coulissant (pas comme l'iphone ;)
  • un appareil photo 5 MegaPixels avec flash double LED et auto-focus
  • un enregistreur vidéo (annoncé de qualité DVD !)
  • un mémoire interne de 8 Go extensible à 32 Go
  • WIFI, Bluetooth, USB 2.0, Micro-SD
  • un GPS, et un logiciel GPS développé par Motorola (malheureusement valable que 60 jours. Après, il faut passer à la caisse)
  • équipé de Android 2.0
  • équipé d'un navigateur intégrant Flash 10 (on va en reparler...)
Vous l'aurez compris, la liste des caractéristiques est plutôt alléchante, et il me tardait d'essayer concrètement l'appareil, pour voir s'il était à la hauteur de son impressionnante plaquette. Vous allez le voir, j'ai eu des bonnes et des mauvaises surprises. Petit retour d'expérience :
  • Tout d'abord, l'esthétique (c'est le premier truc qu'on voit) : on appréciera son grand écran, ses 4 boutons tactiles assez jolis, et une épaisseur assez fine pour un smartphone embarquant un clavier. Néanmoins, je le trouve un peu trop rectangulaire (peu arrondi), et le clavier est assez austère en comparaison au dernier LG GW620.
  • L'écran : l'écran est assez grand, et réagit très bien (écran capactif).
  • Le multi-touch : très fonctionnel pour le zoom sur les photos, et sur les sites internet. Par contre, ne marche bizarrement pas sur les maps (contrairement à un iphone...). Pour cela, il faut double-cliquer.
  • Le clavier : si je ne le trouve pas très esthétique, il est pour autant très efficace, le toucher est agréable et réactif.
  • La rapidité/puissance : globalement, la navigation est fluide et précise (l'écran capacitif aidant). J'ai noté toutefois quelques ralentissements lorsqu'on est sur le slideshow de photos.
  • Les photos : très bonne qualité de photo, même dans un endroit sombre, le double-flash marche très bien, et pas de flou. Les photos sont ensuite partageables sur facebook, myspace, picasa, ...
  • Les vidéos : j'ai été bluffé par la qualité des vidéos prises ! De même pour le son. C'est fluide, de bonne résolution et il y a un stabilisateur d'image. J'ai vu notamment une vidéo d'une piscine où on voit tous les détails des vagues. Par ailleurs, les vidéos sont partageables sur Youtube d'un clic.

Mais, me direz-vous, on est sur un blog technique et orienté développement/technologies, non ? Alors parlons de la star de ce Milestone, Android 2.0 :
  • La recherche : première fonctionnalité testée, la recherche intégrée dans le système d'exploitation. Le test est faussé par le fait que le téléphone est pour ainsi dire vide, mais néanmoins c'est convaincant. En quelques lettres tapées, on retrouve les contacts, les applications, les musiques de notre téléphone. Puis on le voit, dans un deuxième temps, il va chercher sur internet pour compléter la liste. Les résultats sont rapides, très pratique !
  • MySign : voici typiquement l'application qui m'a beaucoup plu. On dessine une lettre au doigt (qui peut être en fait n'importe quel geste), et il ouvre l'application paramétrée ! Très rigolo, mais aussi très ingénieux comme système de raccourci. Ce qui est particulièrement intéressant, c'est qu'on peut définir nos propres gestes, et leurs applications associées.
  • Intégration de Flash 10 dans le navigateur : il s'agit là de ma grande déception. Annoncé partout sur les plaquettes de Motorola, lorsque l'on va avec le téléphone sur un site Flash comme http://beta.parleys.com, on obtient un joli message indiquant que Flash n'est pas supporté... J'ai essayé avec d'autres sites, même problème... C'était de loin la fonctionnalité que j'attendais le plus (notamment d'un point de vue performance), et là, j'ai été très surpris et déçu de constater que ce n'est même pas fonctionnel. Les commerciaux nous ont expliqué que ce n'était pas la bonne version, mais je n'ai pas trouvé leurs arguments très convaincants.
  • Vive GWT et l'HTML 5 : Par contre, une application GWT 2.0 et HTML 5, ça marche très bien ! La preuve avec cette superbe application développée par SFEIR (^^) et qui fonctionne très bien sur le Motorola Milestone.

mardi 24 novembre 2009

SLF4J & LOGBack : simplifiez-vous les logs


Mercredi dernier, lors de la première journée de conférences du Devoxx, Ceki Gülcü, nous a présenté deux framework de logs complémentaires SLF4J et logback.


SLF4J

Ceki Gülcü a d'abord commencé sa présentation par la présentation de SFL4J (The Simple Logging Facade for Java), qui consiste en une API (slf4j-api.jar) permettant d'harmoniser les appels de log dans le code Java quelle que soit l'implémentation choisie (log4j ou JUL par exemple). Il explique au passage la possibilité de brancher sur son application utilisant SLF4J une implémentation noop (no operation performed).

Le speaker (et créateur de SLF4J) présente ce dernier comme un potentiel doublon de commons-logging à quelques différences prêt comme le choix de l'implémentation choisie par le framework qui se fait automatiquement (dynamiquement) dans commons-logging et de manière manuelle (statique) dans SLF4J en important le jar adéquat dans le classpath :  slf4j-logj12.jar pour log4j, slf4j-jdk14.jar pour JUL (java.util.logging) ou encore logback-classic.jar pour utiliser logback.

Le speaker est ensuite passé aux choses plus concrètes en montrant quelques exemple d'appel SLF4J, il a notamment mis l'accent sur la possibilité d'utiliser des messages paramétrés qui ne seront construits (i.e. qui ne consommeront de ressources) que s'il doivent être affichés. Pour démontrer son propos il a donné l'exemple suivant :

La vieille méthode La méthode moins naïve mais verbeuse La méthode SLF4J, intelligente et concise
logger.debug("Nom="+nom);
if(logger.isDebugEnabled()){
    logger.debug("Nom="+nom);
}
logger.debug("Nom={}",nom);

Il a ensuite abordé les autres fonctionnalités offertes par SLF4J, parmis lesquelles :

  • L'accès au MDC (Mapped Diagnostic Context) qui permet d'attacher des variables de log à un Thread comme par exemple le login de l'utilisateur ayant fait la requête permettant ainsi de suivre les logs de sa session de manière triviale même au sein de logs complètement entrelacés. Les informations stoquées dans le MDC sont ensuite utilisables directement dans les patterns de log utilisés dans la configuration de la couche de logging.

  • Les Markers hiérarchisés qui permettent en quelque sorte d'affecter des tags aux différents logs. Les applications sont évidemment nombreuses mais Ceki Gülcü a donné un exemple assez simple où les Marker sont utilisés pour marquer les logs "confidentiels" et ou les différents Appender encryptent ces logs "confidentiels". Grâce aux Markers il est donc possible de créer des comportements spécifiques quelle que soit l'origine du log.

SLF4J a ensuite été abordé toujours sous l'angle d'un framework d'uniformisation des logs applicatifs mais cette fois-ci en regardant l'intégration de ce dernier sur des projets utilisant déjà un pou plusieurs systèmes de logs. Il est aisin possible de créer une véritable passerelle entre commons-logging, log4j, JUL avec SLF4J afin de centraliser la gestion et la configuration des logs d'une application. Pour cela il suffit de remplacer les jar d'implémentation du (des) système(s) utilisés (comme commons-logging.jar ou log4j.jar) par des jar d'interception de logs (respectivement jcl-over-slf4j.jar et log4j-over-slf4j.jar). Dans le cas de JUL il faut cependant faire un petit effort de paramètrage (déclaration d'un logger dans le rootLogger).

Pour ceux qui auraient simplement envie de remplacer (et non pas aggreger) le système de logs de leur application, Ceki Gülcü a créé un utilitaire simple de migration vers SLF4J : le SLF4J Migrator

Logback

La créateur du framework nous a d'abord mis dans le bain en définissant LOGBack comme le successeur de Log4J, expliquant brièvement que LOGBack est simplement une évolution de ce dernier (par de rupture conceptuelle).

LogBack est divisé en 3 modules :
  • Logback Core : Module de base étendu par les deux autres modules
  • Logback Classic : Module de log des applications Java (implémente les API SLF4J décrites précédemment)
  • Logback Access : Module d'accès aux logs du conteneur de Servlet (Tomcat, Jetty)

Logback utilise Joran en ce qui concerne la configuration des logs, ce qui signifie qu'il est possible de décrire énormément de choses dans la configuration (contrairement aux configurations sous forme de XML répondant à une DTD statique ou de fichiers properties). il est par ailleurs possible de gérer les inclusions de morceaux de configurations et ainsi rendre le paramétrage des logs extrêmement modulaires au sein d'un projet de grande taille.

Durant sa démonstration des possibilité de logback, le speaker a aussi montrer qu'il est possible de publier des MBeans spécifiques à logback dans JMX et ainsi contrôler les logs dynamiquement via une console comme JConsole (c'est d'ailleurs comme ça qu'il rafraichissait son instance de logback lors des démos).

Filters

Logback offre, à l'instar de log4j, la possibilité d'utiliser des Filtres au sein de la configuration des logs, ce qui permet de prendre (ou non) des logs en fonction de leur correspondance à un filtre. Il est possible de créer des filtres sur des expressions Java complexes (grâce à Juanino qui compile les expression java contenues dans la configuration). On peut par exemple écrire une configuration comme celle-ci avec logback : 

<
appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    
<filter class="ch.qos.logback.core.filter.EvaluatorFilter">
      
<evaluator name="myEval">
        
<expression>message.contains("contenu recherché")</expression>
      
</evaluator>
      
<OnMismatch>NEUTRAL</OnMismatch>
      
<OnMatch>DENY</OnMatch>
    
</filter>
    
<layout>
      
<pattern>
        %-4relative [%thread] %-5level %logger - %msg%n
      
</pattern>
    
</layout>
</appender>

Les expressions n'ont cependant à disposition que les informations contenues dans le LoggingEvent (dont par exemple le MDC, le timestamp de log, le logger, le marker racine ...). Pour plus d'informations sur l'utilisation des filtres, la doc se trouvent ici
Il existe aussi un tpe un peu particulier de Filtre dans logback qui sont les TurboFilter. ces filtres ne sont pas attachés à un appender particulier et sont donc appelés à chaque fois que le système doit créer une évènement de log (donc très tôt dans le processus de log). Il sont utilisés, comme leur nom l'indique, pour accélérer la prise de décision dans la gestion des filtres puisque si un appel au logger ne sera pas loggué à cause d'un TurboFilter (DENIED) alors aucun évènement ne sera diffusé dans le système. Les TurboFilter peuvent par exemple ressembler à ceci :

<
turboFilter class="ch.qos.logback.classic.turbo.MDCFilter">
    
<MDCKey>login</MDCKey>
    
<Value>bobby</Value>
    
<OnMatch>ACCEPT</OnMatch>
</turboFilter>

<turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter">
    
<Marker>inutile</Marker>
    
<OnMatch>DENY</OnMatch>
</turboFilter>

Ceki Gülcü a poursuivi ses démonstrations avec le très intéressant SiftingAppender qui est capable d'encapsuler un appender paramétré (donc plusieurs appender différents au runtime) en fonction d'attributs qui peuvent provenir du MDC (ou d'une valeur par défaut). 
Grâce à ce dernier, il est par exemple possible de créer un appender par login ou par rôle dans une application de manière très simple et sans toucher ou presque au code Java. L'appender suivant définit par exemple un appender par rôle utilisateur en fonction de la valeur role (rôle de l'utilisateur exécutant la requête) contenue dans le MDC :

<configuration>
  
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
    
<discriminator>
      
<Key>role</Key>
      
<DefaultValue>ROLE_USER</DefaultValue>
    
</discriminator>
    
<sift>
      
<appender name="FILE-${role}" class="ch.qos.logback.core.FileAppender">
        
<File>${role}.log</File>
        
<Append>true</Append>
        
<layout class="ch.qos.logback.classic.PatternLayout">
          
<Pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</Pattern>
        
</layout>
      
</appender>
    
</sift>
  
</appender>

  
<root level="DEBUG">
    
<appender-ref ref="SIFT" />
  
</root>
</configuration>

Cette configuration stocke dans le fichier ROLE_USER.log les logs des utilisateurs n'ayant pas de rôle défini dans le MDC. On voit bien ici que plusieurs Appenders vont être instanciés avec chacun un nom différent (FILE-ROLE_USER pour l'Appender par défaut).

Ceki Gülcü a enfin terminé en soulignant une petite fonctionnalités tout à fait intéressante de logback qui permet de suffixer les lignes de logs d'une stacktrace d'erreur par le nom et la version du jar utilisé, ce qui permet lors du debug d'erreur de récupérer instantanément cette information cruciale. 

Exemple de log généré : 
java.lang.NullPointerException at com.xyz.Wombat(Wombat.java:57) ~[wombat-1.3.jar:1.3] 
at com.xyz.Wombat(Wombat.java:76) ~[wombat-1.3.jar:1.3] 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.5.0_06]
...

Synthèse

Pour terminer, nous pouvons dire que, étant nous mêmes utilisateurs de log4j sur nos projets quotidiens, Ceki Gülcü nous a convaincu que logback est bel et bien une évolution de Log4j (et non pas une révolution) et qu'il semble très attrayant de tenter de passer à ce nouveau framework (qui propose qui plus est nativement les API SLF4J) 
A essayer donc !

Ressources

Blog de Ceki Gulcu : http://ceki.blogspot.com/
Une présentation du Jazzon09 quasi-similaire à celle du Devoxx par le même speaker : http://beta.parleys.com/#id=357&st=5

lundi 23 novembre 2009

Atmosphere, atmosphere


Au devoxx de cette année nous avons pu assister à la présentation du framework Atmosphere par Jean-François Arcand, créateur du framework et Paul Sandoz, contributeur sur le projet Jersey utilisé par Atmosphere en ce qui concerne les aspects REST.

Après une rapide présentation des concepts liés aux architectures PUSH pour les applications WEB. Les deux speakers sont rentrés dans le vif du sujet en développant en direct une petite application permettant de démontrer les possibilités offertes par Atmosphere.



Le PUSH ?

Dans les applications WEB, le PUSH correspond à l'utilisation des protocoles WEB pour permettre aux différents clients (navigateurs généralement) de se voir notifier des informations de la part du serveur sans avoir à faire des requêtes périodiques sur ce dernier. Comme son nom l'indique, les informations sont poussées du serveur vers le(s) client(s) et non plus tirées par chaque client désireux d'y avoir accès. L'intérêt d'une telle technique réside dans la possibilité de voir se propager rapidement une modification de l'état du serveur et atteindre ainsi un pseudo temps-réel tout en économisant des échanges réseaux inutiles. Avec le PUSH on peut par exemple dans le cas d'un tchat, propager les nouveaux messages d'une discussion du serveur vers les clients connectés de manière quasi instantanée.
Lors de cette conférence Jean-François nous a décrit les trois types de communications existantes dans les applications WEB à savoir :
  • Polling (technique traditionnelle)
  • Ajax PUSH  ou Long Polling : ce que propose Atmosphere
  • Http Streaming : Une technique idéale théoriquement mais qui souffre de problème d'intégration avec les proxys notamment.
Atmosphere est un framework (le premier) à base de POJO proposant aux développeurs d'applications PUSH une couche de programmation masquant la complexité des serveurs Java dans ce domaine.
Pour développer la partie serveur d'une application, le framework est utilisable sur de nombreux serveurs : des conteneurs legers (Tomcat, Jetty), certains serveurs d'applications comme Glassfish et Weblogic, il est même disponible pour le Google App Engine. Concernant ce dernier, on est en droit de se demander comment peut fonctionner le Long Polling avec des requêtes censées durer moins de 30s ? Jean-François nous a donné la solution en expliquant qu'Atmosphere implémente sont propre système de continuation permettant de passer outre cette contrainte. Il faut aussi noter la compatibilité d'Atmosphere avec les Servlets 3.0.

En ce qui concerne la partie cliente des applications, de nombreux frameworks sont supportés dont GWT et Wicket. 
Lors de la présentation, les speakers se sont focalisés sur une sous-partie du framework à savoir les annotations disponibles pour les POJOs et les aspects REST intégrés via Jersey.

Lors de la démo, les deux conférenciers ont pu nous démontrer la simplicité avec laquelle il est possible de créer une application WEB asynchrone utilisant le PUSH. Ils ont insisté sur le fait d'utiliser de simples POJO et de les rendre manipulables via REST. On obtient par exemple des classes ressemblant à ceci :

@Path("/{topic}")
@Produces("text/plain;charset=ISO-8859-1")
public class PubSub {
    private @PathParam("topic") Broadcaster topic;
    @GET
    @Suspend
    public Broadcastable subscribe() {
        return new Broadcastable("OK",topic);
    }
    @POST
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    @Broadcast
    public Broadcastable publish(@FormParam("message") String message){
        return new Broadcastable(message,topic);
    }
}
L'idée principale de cette démo était d'utiliser Atmosphere pour suspendre la connection client lorsqu'il s'incrit à un topic "test" en appelant http://mon_serveur/test. Un autre client peut alors publier des messages qui seront diffusés à tous les clients connectés sur ce topic en soumettant un simple formulaire HTML contenant un paramètre "message" sous forme textuelle.

Ce que nous aurons retenu

Atmosphere simplifie effectivement le travail des développeurs en ce qui concerne la gestion du PUSH dans une application Java. Il n'est pas nécessaire de refondre entièrement une application existante pour y intégrer Atmosphere, la plupart des problèmes d'intégration sont adressés par le framework (gestion des proxys pour les connections HTTP, les limitations de chacun des navigateurs).

Resources:
Le site du projet : http://atmosphere.dev.java.net
Blogs :
Twitter : 
    @atmosphere_java 
    @jfarcand 

Ludovic Meurillon et Vincent Bostoen

vendredi 20 novembre 2009

Analyse de code avec maven

Intro

Maven, outil de build que l’on ne présente plus, nous rend encore un immense service en nous proposant de générer un site de présentation du projet.

J’aimerais dans cet article vous montrer les différents rapports de code que l’on peut ainsi  agréger et déployer, afin de présenter le projet ou pour en améliorer la qualité.

Je vous propose d’utiliser comme exemple un projet Open source hébergé sur googlecode, nommé gwt-mvc http://code.google.com/p/gwt-mvc/, choisi au hasard J

Voici le résultat : http://gwt-mvc.googlecode.com/svn/site/0.3/index.html


Rapports

 

Voici les différents plugins utilisés :

maven-project-info-reports-plugin http://maven.apache.org/plugins/maven-project-info-reports-plugin/

Plugin principal du site, permet de sélectionner les rapports de base

 

maven-javadoc-plugin http://maven.apache.org/plugins/maven-javadoc-plugin/

Génère la javadoc du projet.

 

maven-jxr-plugin http://maven.apache.org/plugins/maven-jxr-plugin/

Présente le code source avec des liens entre les classes, afin de pouvoir naviguer dans le code en dehors d’un IDE, pratique pour les projets Open Source.

 

maven-surefire-report-plugin http://maven.apache.org/plugins/maven-surefire-plugin/

Rapport de passage des tests unitaires.

 

maven-pmd-plugin http://maven.apache.org/plugins/maven-pmd-plugin/

Rapport de code avec PMD. Cela permet de vérifier la conformité du code avec des règles de codage prédéfinies. Ces règles peuvent être très poussées, mais la plus représentative est "Dans un  block catch, si une exception est relancées, elle doit être construite avec l'exception intiale en tant que cause". Inclus également le rapport Copy Past Duplication, mettant en avant les duplications de code. Il est même possible de bloquer le build en cas de non-respect de règle.

cobertura-maven-plugin http://mojo.codehaus.org/cobertura-maven-plugin/

Rapport de couverture de test.

 

maven-dependency-plugin http://maven.apache.org/plugins/maven-dependency-plugin/

Analyse des dépendances directes et indirectes, et distinction des dépendances : utilisée directement mais sans déclaration (directe), déclarées mais non utilisées.

 

versions-maven-plugin http://mojo.codehaus.org/versions-maven-plugin/

Rapport de mise à jour des dépendances et des plugins.

 

dashboard-maven-plugin http://mojo.codehaus.org/dashboard-maven-plugin/

Agrège les résultats de certains des rapports précédents, et les présente avec de jolis graphiques.

 

Intégration à Eclipse

Ces rapports étant éloignés de l’IDE, l’idéal est de pouvoir retrouver ces mêmes résultats au plus près du code, afin d’avoir deux outils complémentaires.

 

M2clipse http://m2eclipse.sonatype.org/ http://m2eclipse.sonatype.org/update/

Ce plugin permettra à Eclipse d’interpréter la configuration maven afin de compiler le projet.

 

JUnit

Intégré nativement à Eclipse, il vous permet de passer vos tests unitaires.

 

Eclemma  http://www.eclemma.org/ http://update.eclemma.org/

Eclemma vous permet d’obtenir votre couverture de test en utilisant emma. (Cobertura etait utilisé dans les rapports)

 

PMD http://pmd.sourceforge.net/ http://pmd.sourceforge.net/eclipse

Permet d’effectuer les contrôles du respect des règles de codage. Il est important de configurer ces outils avec le même ruleset, et de choisir avec précaution ces règles.

Ici, j’ai utilisé les règles proposées par le plugin PMD eclipse.

 

Conseils

Fixer les numéros de versions des plugins utilisés, afin d’avoir un build répétable.

Placer vos mots de passe dans les fichiers .settings, pas dans le pom, ou alors choisissez le mode interactif (vos identifiants vous seront demandés pendant l’execution).

 

Trucs et astuces

Pour afficher l’arbre des dependances de votre projet :

mvn dependency:tree

(Inclus dans le rapport « Dependencies » mais tellement pratique)

 

Pour savoir si vous utilisez la dernière version de vos plugins (y compris les rapports) :

mvn versions:display-plugin-updates

(Inclus dans le rapport « Plugin Updates Report »)

 

Problèmes rencontrés

J’aurais aimé pouvoir faire le site-deploy en une seule fois, mais wagon-svn ne fournit pas encore l’option qui permet de spécifier un fichier de configuration appellé auto-props, permettant d’associer un mime-type à une extension de fichier.

https://wagon-svn.dev.java.net/issues/show_bug.cgi?id=4

J’ai donc été obligé de générer le site dans un premier temps, puis de modifier les propriétés mime-type dans un second temps.

 

Recherche d’ artifact

Je vous conseille également les sites suivants pour « retrouver » des artifacts, leurs différentes versions, et sur quel repository ils sont disponibles.

http://merobase.com/

http://mvnrepository.com/

http://www.mvnbrowser.com/

 

Il existe des dizaines de sites proposant ce service, mais ceux-là ont un truc en plus, je vous laisse les découvrir.

 

Sources

http://beta.parleys.com/#sl=1&st=5&id=625

http://maven.apache.org/guides/mini/guide-site.html

http://blog.fastconnect.fr/?p=275

 

Bonne génératon de site.

 

Pom.xml

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

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

            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

 

            <modelVersion>4.0.0</modelVersion>

            <groupId>com.googlecode.gwt-mvc</groupId>

            <artifactId>gwt-mvc</artifactId>

            <version>0.3</version>

            <packaging>jar</packaging>

            <name>gwt-mvc</name>

            <description>

                        gwt-mvc Project, an MVC layer on Google Web Toolkit

            </description>

            <url>http://code.google.com/p/gwt-mvc/</url>

            <licenses>

                        <license>

                                   <name>The Apache Software License, Version 2.0</name>

                                   <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>

                                   <distribution>gwt-mvc-repository</distribution>

                        </license>

            </licenses>

 

            <repositories>

                        <repository>

                                   <id>maven2-repository.dev.java.net</id>

                                   <name>Java.net Repository for Maven</name>

                                   <url>http://download.java.net/maven/2/</url>

                        </repository>

                        <repository>

                                   <id>gwt-maven-repository</id>

                                   <url>

                                               http://gwt-maven.googlecode.com/svn/trunk/mavenrepo

                                   </url>

                        </repository>

            </repositories>

 

            <scm>

                        <!-- http://maven.apache.org/scm/subversion.html -->

                        <connection>

                                   scm:svn:http://gwt-mvc.googlecode.com/svn/trunk/gwt-mvc

                        </connection>

                        <developerConnection>

                                   scm:svn:https://${username}:${password}@gwt-mvc.googlecode.com/svn/trunk/gwt-mvc

                        </developerConnection>

                        <url>http://code.google.com/p/gwt-mvc/source/browse/</url>

            </scm>

 

            <distributionManagement>

                        <repository>

                                   <id>gwt-mvc-repository</id>

                                   <url>svn:https://gwt-mvc.googlecode.com/svn/repository</url>

                        </repository>

                        <site>

                                   <id>gwt-mvc-site</id>

                                   <url>

                                               svn:https://gwt-mvc.googlecode.com/svn/site/${version}

                                   </url>

                        </site>

            </distributionManagement>

 

            <build>

                        <extensions>

                                   <extension>

                                               <groupId>org.jvnet.wagon-svn</groupId>

                                               <artifactId>wagon-svn</artifactId>

                                               <version>1.9</version>

                                   </extension>

                        </extensions>

                        <plugins>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-compiler-plugin</artifactId>

 

                                               <configuration>

                                                           <source>1.5</source>

                                                           <target>1.5</target>

                                                           <compilerVersion>1.5</compilerVersion>

                                               </configuration>

                                   </plugin>

                        </plugins>

            </build>

 

            <dependencies>

 

                        <dependency>

                                   <groupId>com.google.gwt</groupId>

                                   <artifactId>gwt-user</artifactId>

                                   <version>1.6.4</version>

                                   <scope>provided</scope>

                        </dependency>

 

 

                        <!-- ControllerTestCase compilation -->

                        <dependency>

                                   <groupId>junit</groupId>

                                   <artifactId>junit</artifactId>

                                   <version>4.5</version>

                                   <scope>provided</scope>

                        </dependency>

                        <dependency>

                                   <groupId>org.jmock</groupId>

                                   <artifactId>jmock</artifactId>

                                   <version>2.5.0</version>

                                   <scope>provided</scope>

                        </dependency>

                        <dependency>

                                   <groupId>org.jmock</groupId>

                                   <artifactId>jmock-legacy</artifactId>

                                   <version>2.5.0</version>

                                   <scope>provided</scope>

                        </dependency>

 

            </dependencies>

 

            <reporting>

                        <plugins>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>

                                                           maven-project-info-reports-plugin

                                               </artifactId>

                                               <reportSets>

                                                           <reportSet>

                                                                       <reports>

                                                                                  <report>index</report>

                                                                                  <report>licence</report>

                                                                                  <report>dependencies</report>

                                                                                  <report>plugin-management</report>

                                                                                  <report>plugins</report>

                                                                                  <report>summary</report>

                                                                                   <report>scm</report>

                                                                       </reports>

                                                           </reportSet>

                                               </reportSets>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-javadoc-plugin</artifactId>

                                               <version>2.6</version>

                                               <reportSets>

                                                           <reportSet>

                                                                       <reports>

                                                                                  <report>javadoc</report>

                                                                                  <!-- <report>test-javadoc</report> -->

                                                                       </reports>

                                                           </reportSet>

                                               </reportSets>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-jxr-plugin</artifactId>

                                               <version>2.1</version>

                                               <reportSets>

                                                           <reportSet>

                                                                       <reports>

                                                                                  <report>jxr</report>

                                                                                  <!-- <report>test-jxr</report>-->

                                                                       </reports>

                                                           </reportSet>

                                               </reportSets>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-surefire-report-plugin</artifactId>

                                               <version>2.4.3</version>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-pmd-plugin</artifactId>

                                               <version>2.4</version>

                                               <configuration>

                                                           <targetJdk>1.5</targetJdk>

                                                           <rulesets>

                                                                       <ruleset>/pmd/pmd-plugin-rules.xml</ruleset>

                                                           </rulesets>

                                               </configuration>          

                                   </plugin>

                                   <plugin>

                                               <groupId>org.codehaus.mojo</groupId>

                                               <artifactId>cobertura-maven-plugin</artifactId>

                                               <version>2.3</version>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.apache.maven.plugins</groupId>

                                               <artifactId>maven-dependency-plugin</artifactId>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.codehaus.mojo</groupId>

                                               <artifactId>versions-maven-plugin</artifactId>

                                               <version>1.1</version>

                                               <reportSets>

                                                           <reportSet>

                                                                       <reports>

                                                                                  <report>dependency-updates-report</report>

                                                                                  <report>plugin-updates-report</report>

                                                                                  <!--                     <report>property-updates-report</report>-->

                                                                       </reports>

                                                           </reportSet>

                                               </reportSets>

                                   </plugin>

                                   <plugin>

                                               <groupId>org.codehaus.mojo</groupId>

                                               <artifactId>dashboard-maven-plugin</artifactId>

                                               <version>1.0.0-beta-1</version>

                                   </plugin>

                        </plugins>

 

            </reporting>

 

</project>

 

mercredi 18 novembre 2009

DEVOXX 2009 - Conference Day 1 - Keynote

Premier jour à DEVOXX 2009 pour SFEIR, et premier jour de la partie "Conference" de DEVOXX.

Ca commence fort : Stephan JANSSEN (principal organisateur de DEVOXX) demande s'il y a des gens de SFEIR dans la salle, en précisant qu'on est venu à 24 au total ! Nous sommes surpris de notre popularité !







Stephan JANSSEN enchaine alors par quelques chiffres clés afin de se rendre compte de l'importance de l'événement :
- 8e édition
- plus de 2500 inscrits
- 737 entreprises
- 212 étudiants
- 132 sessions
- 120 speakers
- 56 JUGs
- 36 pays
- 19 partenaires

Il poursuit sur la présentation de Parleys.com V3, la plate-forme de e-learning dont il est le principal contributeur, et qui fête aujourd'hui ses 3 ans. Cette version est actuellement disponible sur : http://beta.parleys.com
Au programme des nouveautés de cette V3 :
- la possibilité de créer des espaces
- la possibilité de personnaliser son espace (par CSS)
- la possibilité d'avoir sa propre URL (monnom.parleys.com) pour son espace

Au programme de la version suivante (V4) :
- un client iphone (Stephan souligne que c'est à cause du système de validation de l'Apple Store que cette évolution n'est pas présente dans la V3)
- un système de pay-per-view, qui permet au visionneur de rémunérer le speaker de la session.

Il a également annoncé que comme l'an dernier, toutes les vidéos de DEVOXX 2009 seront publiées sur parleys.com tout au long de l'année (à hauteur de deux sessions par semaine) et disponibles gratuitement.
Pour ceux qui seraient pressés d'avoir accès à toutes les vidéos, une formule payante (49 euros pour 6 mois d'accès illimité) sera possible et permettra seulement une semaine après DEVOXX 2009 d'avoir un accès complet et illimité à toutes les vidéos des conférences.
Courage au passage à l'équipe DEVOXX, car à mon avis, la semaine après DEVOXX, ils auront du pain sur la planche...

Après Parleys, un speaker Oracle a expliqué sa vision du futur de la plate-forme java.
Une démonstration a été faite de Weblogic DM (pour Dynamic Modules), qui permet la modularisation en utilisant OSGI.
Je ne m'étendrai pas sur sa présentation qui, à mon sens, a peu apporté.



Puis Robert Chinicci (spec lead de Java EE 6) a présenté les grandes lignes de Java EE 6.
Il a annoncé que la date de version finale de Java EE 6 sera le 10 décembre 2009.
Il s'est attardé sur les principales nouveautés de Java EE 6 :
- JAX-RS : l'API pour développer des web services RESTfull, en utilisant uniquement des simples classes java (POJO) et des annotations.
- Bean Validation (JSR 303) : l'API pour définir des contraintes par annotation directement sur les entités métier.
Il sera intégré avec JSF et JPA pour que la validation soit automatique dans les frameworks associés. Par ailleurs, on pourra étendre les contraintes en créant ses propres annotations de contraintes.


- Web Profile : le premier sous-profil Java EE. Ce profil est en fait une sous-partie de Java EE 6, qui inclut les principales APIs utilisées pour développer des sites web. En plus de Servlet/JSP/JSTL/JSF, on pourra y retrouver des APIs plus poussées comme Managed Beans, EJB 3.1 lite, JPA et JTA. Ainsi, avec un serveur d'applications implémentant ce profil, on pourra réaliser des applications relativement complètes. Par contre, je vois mal Tomcat implémenter EJB 3.1 lite, JPA et JTA... On verra l'adoption de ce web profile par les serveurs d'applications.
- Servlet 3.0 :
Ont été ici cités : les web fragments, le fichier web.xml désormais optionnel, la configuration de servlets par annotation, la possibilité d'initialisation de librairies partagées, la registration de servlets par programmation (au démarrage), et la possibilité d'intégrer des ressources statiques dans les JARs des frameworks web.
Pour plus de détails sur cette API, vous pouvez lire notre compte-rendu de la soirée Servlet 3 & JSF 2 au Paris JUG.
- Dependency Injection : API permettant de standardiser l'injection de dépendance (JSR 299 et JSR 330).
En plus de l'annotation @Resource (existante dans Java EE 5), a été rajoutée l'annotation @Inject.
Les beans sont découverts au démarrage de l'application.
Possibilité de parcourir le métamodel d'injection, par l'API BeanManager
- EJB 3.1 :
ajout de l'annotation @Singleton (pour un EJB ayant une unique instance)
ajout de l'annotation @Startup (pour l'initialisation d'un EJB au démarrage de l'application)
ajout de l'annotation @Asynchronous (pour déclarer l'invocation d'un EJB comme asynchrone)
possibilité de définir un EJB directement dans un WAR
API EJBContainer pour pouvoir démarrer/exécuter un conteneur EJB dans une application Java SE ou pour les tests unitaires
- JSF 2.0 :
standardisation des facelets
définition de managed beans par annotation
intégration d'AJAX
et même une API JavaScript fournie
Tout comme Servlet 3.0, pour plus de détails sur cette API, vous pouvez lire notre compte-rendu de la soirée Servlet 3 & JSF 2 au Paris JUG.

Une démonstration a ensuite été faite de GlassFish V3, qui est l'implémentation de référence de Java EE 6.
On a alors appris qu'un plugin pour Eclipse existait et la démo en a attesté.
De la démo, on retiendra :
- un démarrage de Glassfish V3 en 3 secondes chrono (merci OSGi)
- une application web sans fichier web.xml (servlet définie par annotation uniquement)
- rechargement à chaud : on enregistre la modification dans Eclipse, on fait F5 dans son navigateur et ça marche ! Le tout en conservant la session utilisateur...
- démonstration de l'ajout simple d'un EJB directement dans l'application web : un EJB simple POJO avec l'annotation @Stateless, une servlet l'intégrant en variable d'instance (@EJB MonEJB monEJB), un appel à l'EJB dans la méthode doGet() de la servlet, hop, on rafraichit le navigateur et ça marche ! Bluffant de simplicité... au point que la salle applaudit
- démonstration de l'intégration d'un module OSGI dans la même servlet, toujours avec aussi peu d'étapes, et une intégration simple par annotation, on recharge le navigateur, et ça marche... Toujours pas de redémarrage du serveur d'applications, vraiment bluffant...


Enfin, Chet Haase (de Adobe) a montré l'ensemble de la gamme des produits d'Adobe, démo à l'appui.
On retiendra :
- Flash 10.1 optimisé pour être compatible avec des smartphones
- l'empreinte mémoire de la VM Flash 10.1 est globalement 2 fois inférieure à celle de la VM Flash 10.0
- une démo a par ailleurs été faite sur un smartphone de l'application parleys.com (qui fait du streaming vidéo), qui était particulièrement fluide.
- BlackBerry/RIM et Google Android sont en train d'intégrer Flash dans leur système
- Pour Apple/iPhone, ils ont indiqué qu'un outil permettait de convertir une application Flash en application iPhone SDK (démo à l'appui...)
- AIR 2.0 apporte plus de rapidité, et ouverture directe des fichiers dans le système d'exploitation
- une démo assez bluffante de Flash Catalyst : transformation de fichiers PhotoShop en une application Flash/Flex en quelques étapes (pour autant, il s'agissait grossomodo de la même démonstration que l'an dernier)

Ainsi se termine ce premier keynote, qui ma foi, fut assez intéressant !
 

lundi 16 novembre 2009

SFEIR en force à DEVOXX 2009 !

Cette semaine, a lieu un événement important pour la communauté java : DEVOXX 2009.
Il s'agit de la deuxième plus grosse conférence mondiale (et la première européenne) autour des technologies java.

Pour la quatrième année consécutive, SFEIR sera présent à l'événement, et pas qu'un peu : pas moins de 20 collaborateurs SFEIR feront le déplacement pour participer à DEVOXX 2009 les mercredi 18 et jeudi 19 novembre !

Pendant ces deux jours, nous essaierons de vous faire partager au mieux l'événement, en publiant des billets sur insideIT relativement aux sessions présentées.

Donc, si vous n'avez pas eu la chance d'avoir votre billet pour DEVOXX 2009, suivez le blog insideIT !

En attendant, voici le programme prévu pour ces deux jours :
- mercredi 18 novembre : http://www.devoxx.com/display/DV09/Conf+Day+1
- jeudi 19 novembre : http://www.devoxx.com/display/DV09/Conf+Day+2

lundi 9 novembre 2009

Les rencontres spring 2009 : SpringSource Updates, keynote par Adrian Colyer

La première session fut animée par Adrian Colyer le CTO de springsource, qui nous a présenté une synthèse des nouveautés du « spring portofolio » et du positionnement de SpringSource dans l’écosystème Java Entreprise. En effet, il a essayé de défendre ce qui était devenu la devise de la compagnie c'est-à-dire «la guerre contre la complexité » en mettant l’accent sur le spectre des produits qu’offre désormais Springsource couvrant le «Build, Run, Manage».

Il a commencé par les nouveautés du «spring-portofolio » et notamment Springframework et sa nouvelle version majeure (la 3ème) qui ne devrait plus trop tarder (une GA est prévue en décembre). Ainsi, en énumérant les nouvelles fonctionnalités apportées à cette version telles que le support REST, l’Expression Langage (SpEL), JavaConfig ou encore l’intégration de la validation déclarative (JSR-303) il a insisté sur la simplicité d’utilisation de ces API/SPI et le respect des valeurs et bonnes pratiques instaurées par la communauté.

Ensuite, il est passé aux autres modules du portofolio dont une nouvelle release était en attente de celle de spring-3. Le premier fut, Spring-Integration qui passera en 2.0. Celui-ci a bénéficié du SpEL, et a vu sa bibliothèque d’adaptateurs bien étouffée (JDBC, TCP/UDP, RSS/ATOM, XMPP…); sans oublier l’implémentation d’encore plus d’« Enterprise Integration Patterns » (http://www.eaipatterns.com/).

Puis il a passé à Spring-Batch, insistant sur le travail fait en vue d’une meilleure intégration avec Spring-Integration, et le nouveau module qui verra bientôt le jour, Spring-Batch Admin. En parlant de nouveau né, c'est-à-dire n’ayant pas encore atteint de release finale, il a cité ROO, le générateur de code basé sur Spring et AspectJ. Qui offrait une alternative purement java à Grails. Et pour finir avec l’axe «Build», il a parlé de STS (Spring ToolSuite), et la bonne nouvelle, c’est que SpringSource est en entrain de travailler sur l’amélioration du support Groovy/Grails, espérons qu’eclipse en bénéficierai aussi.

Pour le «Run », c'est-à-dire les runtimes fournis par Springsource, outre dm server dont la version 2 est proche (GA annoncée fin 2009), il a cité tc server le conteneur web basé sur tomcat. Il a notamment parlé d'une autre nouveauté : Spring tc server Developer Edition (actuellement disponible en preview). C’est un tomcat additionné de Spring Insight, une console de monitoring et de profiling, permettant de plonger dans votre application Spring, et de vous afficher à la fois des informations globales sur les performances, comme une vue détaillée de chaque requête HTTP avec l'URL appelée, les paramètres, les services appelés, et les requêtes SQL appelées.

Partant des serveurs d'applications et de Spring tc server Developer Edition, il a alors effectué une transition naturelle vers le «manage» et Hyperic, qui offre de belles fonctionnalités de management et de monitoring pour plus de 75 technologies.

Pour finir, il a introduit la nouvelle offre née de l’intérêt que porte la compagnie à la vague du cloud computing et matérialisée par Cloud Foundry, qu’il a présenté par le terme « Accelerate time to value, as-a-service ». Il a insisté sur le fait qu’elle associe toute la flexibilité et le savoir-faire acquis par la communauté des produits springsource classiques (Opinionated Software) à la puissance des services cloud d’amazon (notamment EC2) ; cela tout en priorisant le souci de simplicité, avec les « deployment blueprints ».

dimanche 18 octobre 2009

Compte-rendu de la soirée JSF 2.0 / Servlet 3.0 au Paris JUG

Mardi dernier, a eu lieu la soirée JSF 2.0 / Servlet 3.0 au Paris JUG. Comme à l'accoutumée désormais, la salle était comble, Antonio nous a même annoncé que toutes les places étaient prises 24h après l'annonce officielle ! Un conseil donc, si vous souhaitez participer à la prochaine soirée Paris JUG (soirée Google le 10 novembre), ne tardez pas une fois les inscriptions ouvertes !


JSF 2.0

La première partie de la soirée était consacrée à JSF 2.0. En réalité, derrière le titre JSF 2.0, cette présentation montrait les concepts généraux JSF d'une part, et les nouveautés JSF 2.0 d'autre part. On pourra regretter dans ce choix d'intégrer une présentation plus générale de JSF, le fait de voir les nouveautés JSF 2.0 noyées dans la masse et certaines nouveautés peu ou pas expliquées, faute de temps.
Voici les principales nouveautés de JSF 2.0 que j'ai retenu de cette présentation :

  • Possibilité de faire de la validation en utilisant la JSR 303 (Bean Validation) :
    Désormais, en positionnant le tag <f:validateBean> dans vos vues, JSF exécute la validation d'un bean donné en utilisant les annotations JSR 303 positionnées sur chaque attribut du bean. Par ailleurs, Emmanuel Bernard (spec lead de la JSR 303) est intervenu à la fin de cette présentation pour nous expliquer plus en détail l'intérêt de cette spécification : les contraintes de validation sont définies à un seul endroit, l'entité métier, et sont réutilisées par toutes les couches de l'application - présentation, métier, persistance - notamment de manière automatique par les frameworks comme JSF 2.0 ou encore Hibernate. Il nous a également indiqué que la JSR devrait très prochainement être finalisée.
     
  • Nouveau scope 'view' pour les managed beans :
    En plus des scopes classiques application, session et request, un nouveau scope fait son apparition : le scope view. Un bean de scope view sera maintenu par le conteneur tant que l'utilisateur ne change pas de page. Ce scope est donc pratique lorsque l'on souhaite faire plusieurs allers-retours client/serveur avec la même page, et que l'on souhaite conserver l'état de cette page entre chaque aller-retour.
     
  • Possibilité de déclarer des managed beans par annotation :
    Avant, la déclaration de managed-beans devait obligatoirement être faite dans le fichier faces-config.xml. Désormais, il sera possible de déclarer un managed bean par annotation en positionnant @ManagedBean sur le bean en question. Le scope du managed bean devra également être précisé (ex: @RequestScope pour un managed bean de scope request)
     
  • Développement de composants facilité avec EZComp :
    JSF 2.0 apporte la simplification du développement de composants avec EZComp. Avec EZComp, on déclare l'interface d'un composant, puis son implémentation pour un type de rendu donné, et on n'a plus qu'à importer le composant dans nos vues JSF.
    Interface :
    <composite:interface>
    <composite:attribute name="qui" required="true"/>
    </composite:interface>

    Implémentation :
    <composite:implementation>
    <span>Hello #{cc.attrs.qui}</span>
    </composite:implementation>

    Utilisation :
    <html xmlns:ez="http://java.sun.com/jsf/composite/hello">

    <ez:hello qui="world" />

     
  • Gestion native d'AJAX :
    Avant JSF 2.0, pour faire de l'AJAX, il fallait passer par des librairies tierces comme RichFaces. JSF 2.0 fournit désormais le nécessaire out-of-the-box. Ainsi, avec la balise <f:ajax>, on peut facilement intégrer des comportements AJAX dans ses vues, comme la validation en temps réel d'un champ, et sans rechargement de page.
     
  • Templating : intégration de facelets dans JSF 2.0 :
    En JSF 1, il fallait faire appel à la librairie tierce facelets pour faire du templating, JSF 2.0 l'intègre désormais directement. Ainsi, pour faire du templating, il faut d'une part définir un template XHTML définissant le cadre commun de la page et la zone où est insérée le contenu spécifique de chaque vue. Puis dans chaque vue, il faut référencer le template utilisé, puis définir le contenu spécifique de la page.
     
  • Gestion avancée des ressources statiques :
    Il est désormais possible de positionner les ressources statiques soit dans /resources, soit dans /META-INF/resources au niveau des classes de l'application web, ou encore dans les JARs de l'application (de WEB-INF/lib). Cette nouveauté n'est pas sans rappeler celle de Servlet 3.0, comme on le verra plus loin. Au delà de ce mécanisme, il est également possible de versioner les ressources statiques, mais également de les internationaliser. Ainsi, pour une même image, on pourra avoir une version fr_monimage.gif et une autre en_monimage.gif. Ces ressources pourront alors être référencées dans les vues soit par tag, soit par EL.
     
  • Gestion de profils :
    Une nouveauté intéressante, car peu commune, la gestion de plusieurs profils d'utilisation : development, production et unitTest. Avec ces profils, on peut mettre du code ou du contenu conditionné par un profil d'utilisation. Ainsi, par exemple, on pourra en cas d'erreur, afficher la stacktrace dans la page en profil development, et afficher un joli message  d'erreur en profil production.
     
  • Accès aux vues par la méthode GET :
    Enfin, dernière nouveauté qui était fortement demandée par la communauté, les vues seront désormais accessibles par la méthode GET, et plus seulement par la méthode POST. Cela permettra notamment aux utilisateurs de pouvoir créer un favori sur une page donnée.

 

Servlet 3.0

La deuxième partie de soirée était consacrée aux nouveautés apportées par Servlet 3.0. Aux commandes de cette présentation, Rémy Maucherat, responsable de l'implémentation des APIs Servlet & JSP chez JBoss, et membre de l'expert group de la JSR 315 alias Servlet 3.0. Autant dire qu'il maitrisait son sujet !
Au milieu de toutes les nouveautés annoncées, nous avons appris que pas mal de modifications avaient été apportées à cette JSR la semaine dernière même, ce qui est assez surprenant étant donné que la finalisation de cette JSR est très proche.
Voici la liste des nouveautés que j'ai retenu :
  • Possibilité de définir les servlets, filters, listeners par annotation :
    On peut désormais définir une servlet uniquement en positionnant une annotation @WebServlet sur la servlet en question (avec les paramètres associés, notamment les urlPatterns auxquels elle répond). Il en est de même pour les filters et listeners. Ainsi, le fichier web.xml devient optionnel.
    Enfin, il est également possible au niveau d'une servlet, de définir les contraintes de sécurité associées par annotation.
     
  • Possibilité de définir les servlets, filters, listeners par web-fragments :
    Chaque JAR d'un framework donné présent dans WEB-INF/lib peut définir sa configuration XML spécifique dans un fichier META-INF/web-fragment.xml. Ainsi, il sera désormais possible d'ajouter un framework web donné par simple drag&drop du JAR dans WEB-INF/lib, plus besoin d'ajouter de la configuration dans web.xml. Par ailleurs, cette configuration par défaut d'un framework web donné est surchargeable dans le fichier web.xml. On pourra ainsi redéfinir uniquement un init-parameter du controller du framework, le conteneur web se chargera de faire la fusion des configurations.
    Enfin, il est possible de définir l'ordre de chargement des web-fragments, soit dans le fichier web-fragment.xml même (ordre relatif de chargement de ce fragment par rapport aux autres), soit dans le fichier web.xml (ordre absolu des web-fragments chargés).
     
  • Possibilité de définir les servlets, filters, listeners par programmation :
    Au moment du chargement de l'application, il est possible désormais d'ajouter par programmation des servlets, filters et listeners à partir du ServletContext, ce qui permettra des configurations dynamiques (par opposition à la configuration statique) et contextuelles (en fonction de paramétrage d'environnement par exemple). Un exemple d'utilisation qui me vient à l'esprit : les tests unitaires. On pourra ainsi imaginer l'ajout à chaud de la servlet de Cactus lorsqu'une system property est détectée au démarrage de l'application.
     
  • Possibilité de définir des ressources statiques dans un JAR :
    Dans certains cas, on souhaite ajouter dans notre application, un framework ou un outil de monitoring/administration qui a ses propres ressources statiques associées. Aujourd'hui, il faut manuellement ajouter ces ressources à nos ressources applicatives, ce qui est dommage. Pour répondre à cette problématique, il est désormais possible dans Servlet 3.0, d'inclure dans un JAR (de WEB-INF/lib) les ressources statiques associées dans le répertoire META-INF/resources. Ces ressources statiques seront accessibles depuis le web comme si elles étaient positionnées à la racine du WAR.
     
  • Possibilité d'initialiser les bibliothèques partagées :
    Au jour d'aujourd'hui, il y a un certain flou autour de l'initialisation des bibliothèques partagées par plusieurs applications au sein d'une instance de serveur d'applications. Désormais, il sera possible au niveau de la bibliothèque partagée d'avoir un initializer implémentant l'interface ServletContainerInitializer, ayant une méthode onStartup() appelée à l'initialisation de chaque application présente dans le serveur d'applications. Le servletContext de l'application en question sera passé en paramètre. Un usage intéressant que je vois pour cette fonctionnalité est pour les portails (au sens moteur de portlets). Un portail a souvent besoin de rajouter des servlets, des listeners ou des filtres spécifiques au sein des portlets qu'il manage, ce qui est dommage lorsque l'on souhaite avoir des portlets standard Portlet 1.0 ou 2.0. Grâce à ce mécanisme, plus celui permettant de définir des servlets/filters/listeners programmatiquement, le portail pourra rajouter à chaud au démarrage du serveur,ses composants spécifiques au niveau de chaque portlet. Ainsi le web.xml de chaque portlet restera standard Portlet 1.0 ou 2.0.
     
  • Possibilité d'exécution asynchrone des servlets :
    Probablement la plus grosse fonctionnalité : la gestion d'exécution asynchrone des servlets. Cette fonction permet de répondre à deux problématiques :
    • le mécanisme de push dans les applications de chat ou les jeux en ligne
    • dans les applications très haute charge, la possibilité de libérer un thread du pool de threads du serveur d'applications pendant le temps où on attend des retours asynchrones du BackOffice du SI, pour les agréger ensuite dans la réponse web.
    Ce mécanisme est très puissant, mais apporte également son lot de complexité. A utiliser donc uniquement si on en a vraiment besoin.
     
  • Gestion des formulaires multi-parties (upload de fichiers) :
    Récupérer côté serveur (simplement) les fichiers envoyés par un client via un formulaire était un manque important, qui avait jusqu'alors été comblé par la librairie Apache Commons FileUpload, largement utilisée. Servlet 3.0 reprend quasiment à l'identique les fonctionnalités permises par cette librairie.
     
  • Possibilité de contrôler le processus d'authentication par le conteneur :
    Un constat est le fait que les mécanismes d'authentification par le conteneur sont peu utilisés car peu flexibles, peu contrôlables. Partant de ce constat, de nouvelles méthodes ont été ajoutées dans l'interface ServletRequest afin de permettre aux développeurs de contrôler le mécanisme d'authentification du conteneur :
    • authenticate(response) : lance le mécanisme d'authentification défini du conteneur 
    • login (username, password) : lance le mécanisme d'authentification du conteneur à partir des identifiants passés en paramètre (nouveau type d'authentification : LOGIN)
    • logout() : permet de forcer la déconnexion de l'utilisateur en supprimant le principal de la session
       
  • Possibilité de personnalisation de la gestion des sessions :
    Désormais, dans la balise <session-config> du fichier web.xml, il est possible de personnaliser la gestion des sessions :
    • possibilité de modifier le nom du cookie de session (par défaut JSESSIONID)
    • possibilité de choisir le mécanisme de récupération de l'id de session : URL, COOKIE, SSL
    • possibilité de redéfinir la portée du cookie de session (par défaut : locale au contexte web de l'application). Cela permet notamment d'activer le partage de sessions entre plusieurs applications au sein d'un même serveur d'applications. Cela sera particulièrement utile pour les portails (encore une fois), pour permettre d'avoir une session commune entre toutes les portlets.
     

Conclusion

En conclusion, beaucoup de nouveautés pour ces deux versions majeures d'APIs, intégrant la spécification Java EE 6. Côté JSF 2.0, on appréciera le fait que Sun ait écouté la communauté (support natif d'AJAX, support de la méthode GET), et le fait d'avoir intégré certains frameworks existants et ayant fait leurs preuves comme Facelets. Mais pour moi, le plus impressionnant est côté Servlet 3.0 : on avait pas vu pareils changements depuis au moins Servlet 2.3 (avec l'arrivée des listeners et filters), et cela fait plaisir à voir. Pour moi, les maîtres mots sont flexibilité (avec quatre moyens de définir des servlets, filters et listeners) et puissance (notamment avec la nouvelle fonctionnalité d'exécution asynchrone des servlets).
Bien sûr, tout le monde ne tirera pas forcément partie de ces nouveautés et continuera à utiliser l'API Servlet comme au bon vieux temps. Mais, je pense que tout cela apportera de nouveaux frameworks, de nouveaux outils qui tireront profit au maximum des nouveautés de Servlet 3.0, et pourquoi pas, apporteront de nouveaux usages...



Références

Slides JSF 2.0
Slides Servlet 3.0

jeudi 11 juin 2009

Eric Evans au Paris JUG lundi 15 juin

Ce cours post pour vous signaler la venue d'Eric Evans au Paris JUG lundi 15 juin (ce lundi) à 19h30 pour une soirée exceptionnelle dans les locaux de l'EPITA (KB).

Eric viendra parler du Domain Driven Design dont il est le fondateur.

C'est une présentation du niveau des grandes conférences telles que Devoxx ou Jazoon, sauf que vous ne payez ni le transport ni la conférence :-)

Inscriptions ici : http://parisjug.org/xwiki/bin/view/Meeting/20090615

mercredi 1 avril 2009

Barcamp sur Android à la Cantine le samedi 28 mars 2009

SFEIR a participé au Barcamp sur Android à la Cantine le samedi 28 mars 2009. Elle a organisé des ateliers de découvertes sur plusieurs sujets d'android le matin du barcamp :

  • Kit de démarrage Android
  • Android Multimédia (2D, 3D, Son)
  • WebServices Android (Interactions avec les APIs Google)
  • Les 4 blocks d'une application Android
  • Démasquer une application android (créer un jeu en 5min)
  • MapActivity et GPS

Vous pouvez retrouver une bonne partie des présentations et codes sources fait lors de ces ateliers sur le nouveau site dédié à Android :

http://www.insideandroid.fr

Voici une vidéo faite pendant l'évènement :


Vidéo du Barcamp sur Android à la Cantine le 28 mars 2009

lundi 16 mars 2009

CR Paris JUG - Partie 2 : Web Sémantique

Suite du compte-rendu de la soirée Wicket & Web sémantique, le premier billet consacré à Wicket est disponible ici.

Alexandre Bertails d’Atos Origin nous a ensuite présenté les dernières avancées en matière de Web Sémantique (ce que devait être le Web 2 et que pourrait être le Web 3).

L’idée du Web Sémantique a germé en 1994, de l’inventeur même du web Tim Berners-Lee. La terminologie « Web Sémantique » ne reflète pas ce que c’est réellement, une version plus exacte pourrait être « Web de données », l’objectif étant de partager ces données, d’en faciliter l’accès, et ceci indépendamment de la logique dont elles pourraient être récupérées/traitées/affichées.

Lire la suite...

dimanche 15 mars 2009

CR Paris JUG - Partie 1 : Wicket

Mardi s’est tenue la réunion mensuelle du Paris JUG. Thèmes de la soirée : Wicket & Web sémantique.

L’équipe a commencé par quelques annonces :

  • Les inscriptions sont désormais obligatoires avec contrôle à l’entrée. Sous quelle forme ? On se cherche encore un peu, imprimer une confirmation d’inscription n’étant pas la solution la plus écologique.
  • Le sponsoring du Paris JUG est remis à zéro en mars, c’est l’occasion de devenir sponsor.
  • Javablackbelt fait une offre pour les juggers : 15 points sont offerts si vous passez par le JUG pour vous inscrire.
  • Un nouveau JUG est en train de voir le jour, le Ch’ti Jug, organisé par Julien Jakubowski et Cyril Lakech : http://chtijug.org/ pour plus d’informations ou directement sur la mailing-list.

Wicket

Carl Azoury et Nicolas André de Zenika nous ont ensuite présenté Wicket, et mis à part les petits problèmes techniques liés à la démo sans filets, on peut dire qu’ils l’ont très bien fait.

D’autre part, Wicket se veut un framework avec un très faible ticket d’entrée : le langage Java et le langage Html, rien d’autre. Pas de configuration XML, pas de configuration par properties, pas de pages JSP ou JSF. Et si on se contente d’utiliser les nombreux composants Wicket, permettant de dynamiser le rendu, pas besoin non plus de faire de JavaScript.

Lire la suite...

jeudi 12 mars 2009

JBoss TattleTale, un outil de vérification de dépendances

Actuellement, j'effectue la migration vers Maven de quelques applications historiques. La difficulté de cette tâche réside dans le dépouillement et l'inventaire des fichiers JAR desquels dépend une application. En effet, on se retrouve face à un amas de fichiers JAR parmi lesquels se trouvent des doublons (mais avec un nom différent ou une version différente), des fichiers appartenant au serveur d'applications (par exemple, servlet.jar ou connector.jar), d’autres qui ne sont plus utilisés par l'application, et parfois même des fichiers de bibliothèques de tests unitaires (par exemple junit.jar). Le travail consiste alors à ne garder que les JAR qui sont réellement utilisés, et d'éliminer avec la plus grande précaution tous les autres. Il va sans dire qu’attaquer un tel problème à « mains nues » n'est pas une mince affaire.

C'est en cherchant un outil de vérification de dépendances que je suis tombé sur l'utilitaire « JBoss Tattletale » qui, à ma grande chance, vient de sortir - en version bêta - des laboratoires de JBoss (voir l'annonce sur le Blog de JBoss).

Cet outil permet de vérifier les dépendances entre les fichiers JAR présents dans un même répertoire considéré comme un classpath. Ses fonctionnalités les plus remarquables sont :
  • Identifier les dépendances entre les fichiers JAR (par exemple, hibernate-3.1.3.jar dépendant de antlr-2.7.6rc1.jar)
  • Lister les classes dont dépend un fichier JAR et lister celles qu'il expose.
  • Lister les classes dont dépend un JAR, mais qui sont absentes du classpath.
  • Lister les classes présentes dans le classepath et les fichiers JAR dans lesquels elles se trouvent
  • Alerter si une classe est présente dans plusieurs fichiers JAR.

L'outil s'utilise en ligne de commande et sa prise en main est rapide. Il génère un rapport au format HTML dans lequel on peut naviguer aisément (voir la capture d'écran ci-contre).

Cet outil m'a vraiment aidé à effectuer la vérification des dépendances lors de la phase préliminaire de migration vers Maven. Malheureusement, il ne dispose pas (pour l'instant?) de plugin Maven permettant l'automatisation de cette tâche (de son coté, ANT dispose déjà d'une tâche tattletale).

Enfin, si vous vous demandez ce que veut dire «tattletale» sa définition se trouve ici. En résumé, «tattletale» est une personne commère qui révèle les secrets. On voit bien que e nom n'a pas été choisi par hasard !
L'outil, qui me semble très prometteur, en est tout juste à ces débuts. Souhaitons-lui un bel avenir!

Liens utiles :

Téléchargement : http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=311046&release_id=665534 (800ko environ)

JIRA : https://jira.jboss.org/jira/browse/TTALE

lundi 9 mars 2009

Android et son SDK

Vous en avez surement entendu parler, Google a sorti dernièrement son système d'exploitation pour mobile : Android. Parallèlement, Google a sorti un kit de développement afin que tout le monde puisse développer des applications et les partager au monde entier. Cet article va vous présenter ce kit de développement et vous présenter les bases à connaitre pour développer une application Android.

Lire la suite...

jeudi 19 février 2009

Intégration de Guice avec les RemoteServiceServlet de GWT

La dernière version snapshot de Guice intégre des fonctionnalités intéressantes pour les Servlets, notamment de nouveaux Builders qui viennent du projet warp-servlet et qui permettent de configurer des mappings de Servlet ou de Filter directement dans un module. Vous pouvez obtenir les sources de l’exemple décrit dans cet article ici.

Au lieu de définir nos RemoteServiceServlet dans le web.xml (ce qui est désormais le cas avec GWT 1.6), nous allons déclarer un GuiceServletContextListener et un GuiceFilter :


 1 <?xmlversion="1.0"encoding="UTF-8"?>
2 <web-app>
3
4
<!-- Default page to serve -->
5 <welcome-file-list>
6 <welcome-filecda.html</welcome-file>
7 </welcome-file-list>
8
9
<listener>
10 <listener-classcom.sfeir.server.CdaGuiceServletConfig
11 </listener-class>
12 </listener>
13
14
<filter>
15 <filter-nameguiceFilter</filter-name>
16 <filter-classcom.google.inject.servlet.GuiceFilter
17 </filter-class>
18 </filter>
19
20
<filter-mapping>
21 <filter-nameguiceFilter</filter-name>
22 <url-pattern/*</url-pattern>
23 </filter-mapping>
24
25
</web-app

GuiceServletContextListener crée une instance d’Injector avec la méthode getInjector(), nous pouvons alors définir notre module en redéfinissant cette méthode :


 1 public class CdaGuiceServletConfig extends GuiceServletContextListener
 2 {
 3     @Override
 4     protected Injector getInjector()
 5     {
 6         return Guice.createInjector(new ServletModule()
 7         {
 8             @Override
 9             protectedvoid configureServlets()
10             {
11                 serve("/cda/echo").with(EchoServiceImpl.class);
12                 serve("/cda/spreadsheet").with(SpreadSheetServiceImpl.class);
13 ...

Nous utilisons pour cela une classe anonyme qui hérite de ServletModule : les méthodes «serve» et «filter» de cette dernière nous permettent de faire l’équivalent de huit lignes de XML pour déclarer une Servlet ou un Filter en une seule ligne de Java.

«serve» fonctionne directement avec les RemoteServiceServlet de GWT (il faut néanmoins ajouter y l’annotation Singleton), par contre les scopes Session et Request de la classe ServletScopes ne peuvent pas être utilisés : nous allons devoir hériter de la classe RemoteServiceServlet pour y ajouter notre propre Scope Session et par la même occasion ajouter un champ «injector» qui contiendra l’objet Injector créé par notre classe CdaGuiceServletConfig.

Dans notre ServletModule, nous rajoutons un appel à «bind» qui associe l’interface SpreadsheetManager à une implémentation :


 1                 bind(SpreadsheetManager.class).
2 to(SpreadsheetManagerImpl.class);

Ainsi l’appel de getInstance de l’object Injector avec SpreadsheetManager.class en paramètre renverra une instance de SpreadsheetManagerImpl.


 1 @Singleton
2 public class SpreadSheetServiceImpl extends GuiceRPCServlet implements SpreadSheetService
3 {
4
5
@Override
6 public List<String> fetchSpreadsheetList()
7 {
8 SpreadsheetManager manager = injector.getInstance(SpreadsheetManager.class);
9 ...

Par défaut, l’Injector de Guice renvoie toujours une nouvelle instance. Nous pouvons également utiliser l’annotation Singleton ou dans le cas présent notre propre annotation GwtSessionScoped afin qu’une même instance soit réutilisée, par exemple le temps d’une session.


 1                 bindScope(GwtSessionScoped.class,
2 GuiceRPCServlet.SESSION);
3 bind(GoogleService.class).toProvider(
4 SpreadsheetServiceProvider.class).
5 in(GwtSessionScoped.class);

Ainsi les champs injectés de type GoogleService seront créés une première fois puis récupérés dans la session en cours. Ce mécanisme fonctionne quand l’Injector de Guice est appelé, il est donc exclu de l’utiliser sur des champs d’une RemoteServiceServlet.


 1 public class SpreadsheetManagerImpl implements SpreadsheetManager
2 {
3 @Inject
4 private GoogleService service;
5
6
@Inject
7 @Named("user")
8 private String username;
9 @Inject
10 @Named("pass")
11 private String password;
12
13
@Override
14 public void authenticate()
15 {
16 try
17 {
18 service.setUserCredentials(username,password);
19 } ...

L’annotation Named est utile pour injecter objets de même type sans avoir à créer de nouvelle annotation. La méthode statique «named» crée cette annotation pour l’utiliser dans les instructions de binding.


 1                 bindConstant().annotatedWith(named("user")).
2 to("cappelle.florent@gmail.com");
3 bindConstant().annotatedWith(named("pass")).
4 to("*************");

Finalement, Guice permet aussi d’ajouter des fonctions transverses à nos services en «bindant» un intercepteur sur un ensemble de méthodes :


 1                 bindInterceptor(subclassesOf(SpreadsheetManager.class),
2 returns(subclassesOf(List.class)),
3 new LoggingInterceptor());

Ici, LoggingInterceptor est appliqué aux classes qui héritent de SpreadsheetManager et plus particulièrement aux méthodes de ces classes dont le retour est de type List. Les classes d’interception doivent implémenter MethodInterceptor de l’API aopalliance.

Vous aurez sans doute deviné que LoggingInterceptor fait un log des appels de méthode, la sécurité et les transactions étant les autres exemples typiques d’utilisation des MethodInterceptor.

En conclusion, Google Guice constitue une alternative intéressante à Spring pour l’injection de dépendance. Dans certains cas, on pourra également utiliser les méthodes de la classe SpringIntegration afin de réutiliser une configuration XML existante.

Liens :

mercredi 11 février 2009

Le Paris JUG a 1 an

Paris JUG

Ce soir le Paris JUG fêtait son premier anniversaire dans une ambiance chaleureuse.

Quelques chiffres sur l'année passée :

  • Un public composé majoritairement de développeurs seniors et d'architectes ;
  • Le site Web compte 15000 visites pour les 7 derniers mois (majoritairement d'île de France).

A suivi un quicky d'un quart d'heure sur Wicket par Tarik Filali Ansary.
Wicket m'a semblé être un framework recherchant des objectifs similaires à GWT : simplifier la vie des développeurs Java pour la création d'application Web.
Rien n'est plus explicite que quelques exemples.
De plus Wicket semble jouir d'une communauté très active : Wicket Stuff, Wicket Library.

Par la suite, nous avons pu nous rendre compte combien les JUG florissent en France. En effet, cette session avait pour invités d'honneur des représentants de tous les JUG français : Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG), Julien Ripault et Cédric Exbrayat (Lyon JUG).

Puis Christian Frei a présenté Jazoon09 de manière très dynamique.

Ce fut ensuite le tour de Stephan Janssen avec pour sujet Parleys.
J'avais déjà assisté à la présentation de la version Flex de Parleys durant JavaPolis07 mais je ne pense pas me tromper en disant que Stephan a eu beaucoup d'effet sur l'assemblée de Juggers en présentant les versions prototype JavaFX et surtout GWT !
Pour la partie moins fun, Parleys proposera bientôt des espaces professionnels pour poster des présentations. Ces espaces seront gratuits pour les JUGs.
Pour finir, Stephan a continué d'envoyer la purée en présentant l'outil de post-processing vidéo qu'il a développé (avec Adobe AIR) pour traiter les enregistrements des conférences Devoxx.

Pour la présentation de Java SE 7 Dolphin, ... et bien, j'étais en train de me faire masser donc je n'ai pas pu prendre de notes ! D'ailleurs merci aux masseurs et aux organisateurs du Paris JUG, c'était un très bonne idée, et toutes mes excuses à Thomas Chamas.
Par contre je me souviens en avoir entendu parler durant une keynote de Devoxx08

Le dernier quicky traitait de l'état de l'art et de l'utilisation de Java dans les jeux vidéo (avec Java Binding for Open GL) par Julien Gouesse.
J'avoue qu'il m'a bluffé. Je ne savais pas que des jeux développés en Java étaient commercialisés même s'ils se comptent sur les doigts.
Pour les personnes intéressées par ce genre de développement, le code source du doom-like TUER développé par Julien est dispo ici.
Par ailleurs, la fluidité de la démonstration du jeu TUER a également bluffé l'ensemble des spectateurs : voir un jeu 3D développé en java aussi fluide, j'avoue que je ne m'y attendais pas.

lundi 2 février 2009

JavaFX : Widgets pour applications professionnelles

Le petit dernier des candidats aux applications RIA, JavaFX, est sorti dépourvu des composants graphiques utiles et nécessaires au développement d'applications à destination des professionnels. Comme Sun semble occupé à mettre le paquet sur une prochaine release en début d'année, incorporant la partie "Mobile", il est peu probable d'en voir arriver tout de suite par le canal officiel.

Alors, quels sont les choix ? Et bien, on se retrouve un peu comme aux débuts de GWT : nous avons un socle technique, il ne reste qu'à retrousser ses manches. Oui mais voilà, tout le monde ne souhaite pas réinventer la roue.

Alors inspirons nous de ce qui a été largement fait pour GWT (par exemple) : le wrapping. Avec GWT il est relativement aisé de wrapper les librairies JavaScript (Ext, SmartClient...) pour pouvoir utiliser les composants existants et souvent de qualité. Avec JavaFX, il est permis de wrapper n'importe quel composant Swing étendant javax.swing.JComponent, autrement dit un nombre assez conséquent :-)

Certes la tâche peut paraitre conséquente - et elle l'est d'ailleurs - mais si une communauté prend autour de JavaFX, des librairies de ce type peuvent rapidement apparaître. Voici un tutorial illustrant comment wrapper la célèbre librairie JFreeChart, tant utilisée par ailleurs !

Lire la suite...

lundi 19 janvier 2009

Compte-rendu de la soirée Java EE 6 et GlassFish V3 au Paris JUG

La semaine dernière s'est tenu la première réunion du Paris JUG de l'année !

Au menu, présentation de la future spécification Java EE 6 par Antonio Goncalves (également co-organisateur du Paris JUG), et présentation du serveur d'applications de Sun - Glassfish - par Alexis Moussine Pouchkine.

La soirée commence avec quelques annonces :

  • La prochaine réunion sera spéciale, le Paris JUG fêtera sa première année (déjà !). Pour l'occasion, les organisateurs des JUG français ainsi que l'organisateur de Devoxx seront présents, et on aura le droit à une série de Quickies sur différents sujets. Tarik Filali Ansary, chef de projet technique chez Sfeir, viendra nous présenter Wicket.
  • Le Paris JUG, attirant de plus en plus de monde, commence à être victime de son succès. Trop de monde, pas assez de budget pour investir dans une autre salle -> inscription obligatoire pour les prochaines réunions.
  • Après XP France, un nouveau groupe d'agilistes est en cours de création, le French Scrum User Group. Lancement prévu le 19 mars, avec Jeff Sutherland himself, rédacteur du manifeste agile et fondateur de Scrum.

Ces annonces faites, Antonio a commencé à nous présenter Java EE 6. Pour info, Antonio est JCP Expert Member de Java EE 6, JPA 2.0, et EJB 3.1. 

Java EE 6

Java EE 6, c'est 28 JSRs, environ 500 pages par spec. Le travail est encore en cours, peu de JSRs ont atteint le statut de public draft, et la sortie est prévue pour mai 2009.
... et présenté par Antonio, c'est façon Daft Punk : richer, easier, lighter !

Richer et en même temps lighter ?

Oui, c'est possible grâce à l'apparition :

  • des EJB Lite. La spécification EJB-lite est un sous-ensemble de la spécification EJB qui supprime notamment le support de RMI, EJB 2.x, Message Driven Bean.
  • des profiles. Le profile "web" permet de supporter la base de "Java EE", et même plus puisque cela inclut les EJB-Lite. Cela permettra à des serveurs d'applications légers d'être certifié sur un sous-ensemble de Java EE 6.
  • du pruning. Plus fort que le deprecated, le pruning doit permettre de se séparer des vieux morceaux obligatoirement présents en raison de compatibilité ascendante. A noter que Entity CMP, JAX-RPC et JAX-R seront "prunées" dans Java EE 6. Cela signifie que ces APIs seront tout simplement supprimées dans la spécification Java EE 7 !

Antonio a ensuite zoomé sur certaines spécifications :

  • Servlet 3.0 : on peut se passer du web.xml en le remplaçant par des annotations. Pour plus de modularité, il sera également possible de casser le web.xml en fragments. La nouvelle version de la JSR permettra également le mode asynchrone. Une partie du mode asynchrone est déjà implementée dans glassfish et permet de faire du reverse Ajax.
  • JSF 2.0 : de nouvelles annotations vont permettre de simplifier le développement d'applications JSF, et comme pour l'API Servlet 3.0, de rendre optionnel le fichier faces-config.xml. JSF 2.0 intégrera facelet.
  • EJB 3.1 : oh ! des annotations. Entre autres, une annotation Singleton, et une autre facilitant la gestion des appels asynchrones (par simple annotation sur une méthode d'EJB). Cela permet de se passer de l'utilisation de JMS qui peut être plus fastidieuse. Nouveauté également, on peut créer facilement un container d'EJBs à la volée (très pratique pour les tests unitaires). La définition d'EJB devient extrêment simplifiée : il suffit de rajouter l'annotation @Stateless pour qu'un simple POJO devienne un EJB, plus besoin de configuration XML lourde. D'autre part, pour un EJB local, une interface de l'EJB n'est plus nécessaire. Enfin, on pourra dorénavant créer des EJBs directement dans un WAR (plus besoin d'un EAR, qui contient un JAR EJB). Ainsi le développement d'EJB devient beaucoup plus simple à mettre en oeuvre pour un développeur. C'est cette simplicité qui a jusqu'ici fait défaut aux EJB, au profit de Spring. Dernier point : les noms JNDI des EJB deviennent portables (plus de nom JNDI adhérent au serveur d'applications).
  • Timer services : une nouvelle syntaxe apparaît (avec des annotations !), s'inspirant de Cron et de Quartz. Séduisant par son apparente simplicité.
  • JPA 2.0 : La spécification JPA 2.0 est désormais complètement indépendante de la spécification EJB, elle n'est plus vue comme un sous-ensemble de EJB (comme c'était le cas dans JPA 1.0, source de confusion). On notera la possibilité d'utiliser JPA 2.0 dans Java SE, de mapper des collections de types simples, d'utiliser des locks pessimistes, et une API "Criteria" (proche d'easyMock dans l'esprit). Rien de nouveau, mais JPA couvrira désormais plus largement les fonctionnalités d'Hibernate.
  • JAX-RS 1.1 : API permettant d'implémenter des Web Services RESTfull. Encore une fois, tout est basé sur les annotations. Il suffit de rajouter l'annotation @Path("/helloWorld") devant une classe POJO et une annotation @GET devant la méthode qui sera appelée pour les appels en méthode GET, pour obtenir une ressource REST. L'API est donc simple à utiliser. A voir pour les cas plus complexes.

Antonio nous a ensuite affiché un arbre représentant la stack technologique Java EE 6. Maintenant, avec la simplicité apportée par Java EE 6, on peut faire une application JSF / EJB / JTA / JPA dans un simple WAR.
Pour finir, on nous a présenté l'implémentation de référence de chaque JSR. GlassFish V3, présenté dans la 2e partie de soirée, sera l'implémentation de référence de EJB 3.1 et Servlet 3.0.

C'est tout pour la présentation de Java EE 6, qui sortira cette année. A noter que Java EE 5 a 3 ans et que la plupart des serveurs d'applications sont compliant Java EE 5 depuis peu, le dernier en date étant JBoss en décembre 2008...

La présentation s'est terminée par une session de questions-réponses, en voici quelques-unes :

  • D'un côté Java EE 6 présente 5 conteneurs différents, de l'autre Spring n'en présente qu'un, pourquoi, quel est l'intérêt ? Antonio répond que le sujet des Web Beans n'est pas tout à fait réglé, sans plus de détails. Nicolas Martignole semble avoir obtenu plus d'informations sur le sujet au cours de la 3ème mi-temps !
  • Pourquoi ne pas mettre plus le focus sur la JSR Servlet 3.0, ça semble pourtant être la principale avancée ? Réponse : Parce que cette spécification a été sujet à controverse, n'est pas finie, et n'est pas des plus faciles à appréhender.
  • JSF est un framework orienté composant, il n'y a rien sur les frameworks orientés actions ? Réponse : en effet !

GlassFish

Quelques retrouvailles / petits fours / t-shirts Glassfish plus tard, Alex Moussine-Pouchkine nous présente GlassFish. Plus précisément GlassFish V3 Prelude, qui est un "prelude to Java EE 6". GlassFish veut être early adopter de la spécification Java EE 6. La plupart des futures spécifications sont d'ailleurs déjà implémentées, en mode preview. On retrouve ainsi JSF 2.0 Preview et EJB3.1 Preview.

Glassfish est à l'origine basé sur Tomcat, mais se veut un serveur d'applications complet.
Alexis commence la session en essayant une comparaison Glassfish / JBoss pas vraiment équitable, puisque les téléchargements GlassFish prennent en compte le nombre de téléchargements du SDK Java EE 5 (Glassfish est inclus dans le SDK Java EE 5).
Glassfish se présente comme étant "au même niveau côté performances" que WebSphere et WebLogic. La mode étant au light (lightweight containers, lightweight ESBs, EJB lite ...), GlassFish se présente comme un "lightweight application server". Glassfish pourrait d'ailleurs être l'un des premiers à se positionner sur les serveurs d'applications "web profile compliant", mais c'est également bien plus, comme on a pu le voir par la suite.

GlassFish se veut avant tout modulaire et extensible. Modulaire car son noyau est basé sur OSGi (ce qui est transparent pour les développeurs). Extensible car basé sur HK2. GlassFish v3 a ainsi un socle ouvert, permettant à tout le monde de pouvoir créer et déployer ses extensions HK2.
Alexis nous fait ensuite une démonstration : GlassFish possède des fonctionnalités intéressantes pour les développeurs, en particulier la sérialisation de sessions HTTP et le “compile on change” (rechargement à chaud des modifications, très pratique en phase de développement). Le démarrage rapide (15 à 20 secondes sur un ordinateur portable), grâce à un système de mise en cache, est également mis en avant. Enfin GlassFish propose un AppStore façon serveur d'applications : l'Update Center. Semblable au apt-get de Debian, l'Update Center permet d'ajouter des briques logicielles à son serveur d'applications. On y trouve par exemple des composants permettant l'intégration de Grails ou Rails.

Côté versions, la 2UR2 (bientôt 2.1) est celle mise en avant commercialement, pour sa robustesse et son support SUN. La V3 définitive sortira vers juin 2009, pour être présentée à JavaOne 2009, et devrait être certifiée Java EE 6. Attention, certains composants Glassfish v2 ne sont pas portés sur Glassfish v3 pour le moment. Ainsi la V3.1, apportant le clustering, sera disponible fin 2009.


Bienvenue au Paris Java User Group !

GlassFish - Open Source Application Server

Résultats du Tableau Blanc lors du buffet


Article rédigé par les sfeiriens du Paris JUG : Fabien Baligand, Tanguy Bayard et Tarik Filali Ansary.

dimanche 14 décembre 2008

Devoxx 2008 - Introduction to the SpringSource dm Server

Cette session avait pour but de présenter le tout nouveau serveur d'applications de chez SpringSource : SpringSource dm Server. Ce petit nouveau a déjà fait couler beaucoup d'encre sur lui, et pour cause, il révolutionne le monde des serveurs d'applications en proposant de déployer les applications non plus sous forme de WARs ou d'EARs, mais sous forme de bundles OSGI, permettant ainsi la modularisation des applications.

J'étais donc curieux de découvrir plus en détails ce produit assez novateur.

Pour commencer, Sam Brannen (Consultant Senior à SpringSource), rappelle les problèmes avec les serveurs d'applications actuels :
  • Alors que les développements sont aujourd'hui de plus en plus pensés de manière modulaire (notamment avec la montée en puissance de Maven en entreprise), toute cette modularité est perdue au déploiement sur les serveurs d'applications avec un WAR/EAR monolithique.
  • De petites mises à jour requièrent un re-déploiement total de l'application (et non pas du seul module mis à jour)
  • Un même module utilisé par plusieurs WARs sera répliqué dans chacun des WARs sur le serveur d'applications, au lieu d'être partagé
  • Il est impossible de faire cohabiter plusieurs versions d'un même module ou d'une même application sur un serveur d'applications classique.
  • Le serveur d'applications lui-même souffre d'un manque de modularité : nous n'utilisons pas toutes les APIs d'un serveur J2EE (ex: toutes les applications n'ont pas besoin d'un conteneur EJB), et poutant toutes les APIs sont chargées en mémoire au démarrage du serveur d'applications, ce qui peut impacter fortement l'empreinte mémoire ou encore le temps de démarrage du serveur.

Je rebondis sur ce dernier point, en précisant que pour les toutes dernières versions de serveurs d'applications, cela a changé : les serveurs Websphere 6, JBOSS 5, Glassfish 3 ou Weblogic 10 sont basés sur un noyau OSGI.
Néanmoins, cela reste très récent...

Sam Brannen poursuit ensuite sur les avantages qu'apporte OSGI, coeur de dm Server :
  • Partitionnement par bundle (pas d'archive monolithique)
  • Renforcement de la visibilité stricte (chaque bundle décrit les bundles qu'il importe, et surtout quels packages précisément il expose aux autres bundles)
  • Résolution des dépendances
  • Versionning (chaque bundle a une version bien identifiée, c'est une donnée obligatoire)
  • Exposition d'un Service Registry
  • OSGi est dynamique : on peut de manière dynamique installer, désinstaller, démarrer, arrêter ou mettre à jour un bundle, et ceci, sans redémarrage du serveur d'applications.

On arrive enfin au coeur du débat, la présentation de dm Server lui-même, qui je dois dire, a été assez brêve à mon gout, pour donner plus de place à des démos :
  • dm Server se base sur le moteur OSGi EQUINOX (moteur qui a l'avantage d'avoir fait ses preuves depuis bien longtemps sur Eclipse)
  • dm Server se base le moteur de servlet Tomcat (il permet ainsi non seulement de déployer des modules OSGi mais également des WARs pour ceux qui hésiteraient encore à sauter le pas)
  • dm Server ajoute à OSGI, un modèle de composant. Ce modèle de composant est justement l'objet de la RFC-124 de l'OSGI Alliance, dont dm Server est la Reference Implementation, et qui devrait être finalisée d'ici Juin 2009. Ainsi, si actuellement, certains peuvent craindre le côté propriétaire du serveur d'applications SpringSource, la standardisation avec la RFC-124 devrait dans l'avenir rassurer... mais aussi créer de la concurrence.
  • D'autre part, dans le principe de fonctionnement, dm Server bootstraps un contexte d'application par bundle (qui n'est pas sans rappeler un certain framework Spring)
  • Enfin, dm Server existe en deux versions :
    • Community Version, qui est free et open source (sous licence GPL et SpringSource License)
    • Enterprise Version, qui offre le support produit et le pack Performance Suite

Sam Brannen termine avec une démo :
  • Montrant dans un premier temps, comment installer le produit, le lancer, le configurer, et l'administrer par console
  • Puis dans un deuxième temps, comment avec le plugin Eclipse "SpringSource Tool Suite", créer un bundle et le déployer sur dm Server.

Je retiens les points intéressants suivants de la démonstration "serveur" :
  • On peut déployer un bundle juste en le déposant dans le répertoire "repository" ou par console
  • La configuration du serveur est stockée en JSON (language jugé plus compact que XML par SpringSource). Je ne suis pas sûr que ce point fasse l'unanimité : si XML est certes moins compact, il est également plus lisible, ce qui pour une configuration, me parait important...
  • Lors d'un crash inopiné du serveur, un thread dump ainsi qu'un heap dump est automatiquement généré dans le répertoire dump (point que je trouve extrêmement pratique en condition de production pour analyser à posteriori la cause du problème). Je vous rassure, sur ce point, il n'en a pas fait la démo ;)
  • Possibilité de définir des profiles (profile web, ...) et de démarrer uniquement ceux désirés. C'est un des avantages principaux mis en avant par un noyau OSGI du serveur : la légèreté du serveur et l'offre à la carte des APIs démarrées.

Je retiens les points intéressants suivants de la démonstration "développement avec Eclipse" :
  • Le plugin Eclipse "SpringSource Tool Suite" est free et open source
  • Le plugin permet de créer une instance de serveur "dm Server" avec WTP (très pratique pour tous ceux qui sont habitués à WTP). Cela permet ainsi de le configurer dans Eclipse, démarrer/arrêter, mais aussi debugger.
  • Le plugin fournit un wizzard de création de projet "Bundle OSGI".
  • Le plugin fournit un éditeur de fichier MANIFEST, permettant l'édition graphique du fichier MANIFEST, ou encore la complétion lors de l'édition du source. Etant donné l'importance du fichier MANIFEST dans un bundle OSGI, et sa potentielle complexité, cet éditeur de MANIFEST est une très bonne idée de la part de SpringSource ; qui plus est, il est très bien fait.
  • Pour ce qui est du développement pur, il suffit d'ajouter l'annotation @Service devant une classe pour qu'elle devienne un service OSGI.
  • Enfin, pour le déploiement du bundle, un simple drag&drop du projet dans l'instance "dm Server" de l'onglet "Servers", et le déploiement est effectif ! (petit effet de style toujours efficace lors d'une démonstration...)

Au final, j'avoue avoir assez apprécié cette présentation, qui fût tout de même assez riche en une heure de temps.
J'ai été particulièrement séduit par le plugin Eclipse fourni par SpringSource, qui se révèle relativement complet et efficace (le tout en open source).
Pour autant, j'aurai aimé la démonstration de l'une des promesses de dm Server : la mise à jour à chaud. Lorsque l'on met à jour un bundle, toutes les requêtes envoyées à ce bundle par d'autres bundles sont mises en attente jusqu'à ce que le déploiement de la mise à jour soit terminée.
Cette démonstration a été faite lors d'une autre session le vendredi (dommage, je partais le jeudi soir) retranscrite sur le blog de notre confrère Octo : DM Server : from WAR to Web Module


Pour finir sur une note plus large, je pense que la révolution OSGI est en marche...
Après avoir conquéri le domaine de l'embarqué (domaine qui a fait naître OSGI), puis le domaine de l'IDE (avec Eclipse Equinox et les plugins Eclipse), OSGI est aujourd'hui est en train de conquérir le domaine des serveurs d'applications (avec comme je le disais, tous les derniers serveurs d'applications sortis basés sur un noyau OSGI : Websphere 6, JBOSS 5, Glassfish 3 ou Weblogic 10). C'est en soi une mini-révolution dans le domaine des serveurs d'applications (qui a d'ailleurs demandé aux éditeurs de refondre entièrement le noyau de leur serveur).
Prochaine étape : les applications d'entreprise.
Avec SpringSource dm Server, le travail de l'OSGi Enterprise Expert Group, et la sortie mi-2009 d’OSGi R4.2 incluant la version finale de la RFC-124 ; je pense que les applications d'entreprise prendront prochainement le virage du WAR/EAR au module OSGI, bouclant ainsi la révolution OSGI en marche.

L'avenir nous le dira...

- page 1 de 2