insideIT.fr : le blog des architectes IT de SFEIR

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

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

Unification reloaded

Deuxième journée de DEVOXX 2009, qui commence par une Keynote très attendue et à mon avis orientée BSBS "Be Simple Be Smart". Je m'explique : Ivar Jacobson , le père d'UML, est un personnage atypique qui n'a pas hésité pas à parler d'une réalité tout aussi controversée que la démultiplication des méthodologies où, selon ses termes, des pratiques qui ne cessent de fleurir régulièrement et qui génèrent beaucoup de problèmes d'apprentissage, de maîtrise, et bien évidemment de compréhension.

Lire la suite...

jeudi 19 novembre 2009

Devoxx 2009 : Agile Mythbusters

Scott W. Ambler, Chief Agile Methodologist chez IBM, a présenté les résultats des sondages réalisés par Ambysoft et Dr. Dobb's Journal pour faire ressortir les pratiques réelles des équipes agiles à ce jour.

Les conclusions qui ont retenu mon attention :

  • les pratiques agiles restent principalement concentrées sur la technique (Continuous Integration) ;
  • l'obtention de la certification "SCRUM Master" après seulement deux jours de formation est dépourvue de sens ;
  • des équipes de plus de 200 personnes pratiquent l'agilité ;
  • les pratiques agiles ne changent pas les besoins de chiffrage, de spécification, de modélisation, d'architecture durant l'initialisation d'un projet ;
  • la majorité des développeurs agiles suivent des conventions de codage même s'il reste une marge de progrès dans ce domaine ;
  • les équipes agiles et traditionnelles écrivent autant de documentation et cette documentation est de qualité similaire ;
  • les projets agiles connaissent plus de succès que les projets classiques.

L'intérêt principal de cette présentation a été de fournir des réponses chiffrées aux questions que peuvent se poser les personnes s'intéressant aux méthodes agiles. Cependant, il convient de considérer ces chiffres dans leur contexte avec les limitations que ça implique. Par exemple, les conditions de succès d'un projet restent sujet à discussion.

Pour la liste complète des "Mythes Agiles" et les résultats des sondages associés, se référer au post de Jevgeni Kabanov.

Pour la liste des sondages, suivre ce lien.

mercredi 18 novembre 2009

Flash Catalyst

  • Flex est un framework open source pour créer des applications web riches
  • Flash builder : Plugin eclipse pour construire des applications flex
  • Flash Catalyst : Logiciel pour faire le lien entre le designer et le developpeur flex.

Flash Player 10 est maintenant présent sur 93,5% des ordinateurs connectés dans le monde, en seulement 10 mois après sa sortie, et est disponible sur tous les navigateurs et systèmes d'exploitation.

Il possède une large communauté en s'ouvrant à elle de plus en plus (les spécifications FLV, SWF, AMF, RTMP sont ainsi disponibles).

Flex :

  • MXML : interface
  • Action Script 3 : code

Compilé en un fichier .SWF et exécuté par le Flash player ou packagé dans un fichier AIR et exécuté sur l'ordinateur.

Jusque-là, le designer visuel (qui utilise Photoshop et Illustrator) et le designer d'interactions (Flash) envoyaient leurs fichiers aux developpeurs qui s'occupaient d'intégrer tant bien que mal le tout dans l'application.

Flash Catalyst permet une interaction directe entre le designer graphique et le designer d'interaction mais aussi avec l'utilisateur qui peut tester le prototype et enfin le developpeur qui peut alors importer et utiliser tout ce travail directement dans Flash Builder.

Flash Catalyst permet de faire des interfaces en wireframes pour rapidement valider l'organisation d'une application. Des fonctionnalités de base pour dessiner des formes sont possibles mais le plus important est peut-être le fait de pouvoir créer les différents états (ou pages) de notre application et définir simplement les actions basiques possibles (clique sur un bouton et changement de page). Il est aussi possible de définir les effets entre les états de l'application.

Ce qui est vraiment le plus impressionnant est le moment où l'on importe un fichier photoshop (ou illustrator) créé par le graphiste qui contient alors tous les visuels de l'application dans des calques ou des éléments différents. Il suffit alors de sélectionner le cadre et le texte qui représente un champ de saisie pour indiquer à Flash Catalyst de le transformer en TextBox Flex qui prendra alors l'apparance définie par le graphiste.

On peut ensuite créer un composant personnalisé qui pourra être réutilisé dans une autre application.

Une fois l'interface définie, on peut directement prévisualiser le rendu directement dans le flash player.

Une fois la partie de design et d'intégration terminée, il suffit alors de générer un projet flex. En ouvrant le projet avec Flash Builder, on y retrouve tous les composants créés, mais aussi les images et tout ce qu'il faut pour faire fonctionner le projet. Une nouveauté dans Flash builder, la possibilité de configurer simplement l'accès aux données via de nombreux services (blazeDS, PHP, HTTP, etc.), des assistants nous permettent d'afficher les services disponibles sur le serveur et de les plugger aux composants de l'interface.

La démonstration est vraiment convainquante. 

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