J2EE
GWT 2.0 : les nouvelles fonctionnalités
14/01/10
La version 2.0 de GWT (Google Web Toolkit) est sortie (j’ai un peu de retard à cause du boulot
) et avec elle de nombreuses améliorations, principalement pour améliorer le développement des applications. Cette nouvelle version est accompagnée d’un outil d’analyse des performances des sites : Speed Tracer, qui donne des pistes d’amélioration de l’application.
Development Mode
Dans les versions précédentes de GWT, pour tester une application en cours de développement, il y avait le Hosted Mode. C’est une application que l’on lançait depuis son IDE, qui démarrait un serveur Tomcat et qui permettait de tester “rapidement” sont application Web.
En GWT 2.0 le Hosted Mode est remplacé par le In-Browser Development Mode. On installe un plugin (le GWT Developer Plugin) dans son navigateur pour lui permettre de communiquer avec la JVM. Cela permet de bénéficier des différents plugins de son navigateur (Firebug, …) tout en permettant de modifier le code Java en live en rafraichissant la page Web.
UI Binder
Un des problèmes majeurs de GWT dans ses versions précédentes est la gestion de l’interface graphique depuis le code Java. La manipulation des Widgets (composants graphiques dans GWT) depuis le code Java pour leurs appliquer des styles CSS ou gérer des événements finit par donner du code difficile à maintenir.
GWT 2.0 apporte une solution plutôt élégante avec l’UI Binder, ça permet de lier un template XML à une classe Java. Au passage, les fichiers CSS et JavaScripts (librairies externes) référençaient depuis le template sont compressées par le compilateur GWT afin d’en réduire la taille finale.
Ainsi, on sépare l’interface graphique (dans les template .ui.xml) et la logique de l’application dans le code Java.
Code Splitting
Voilà une fonctionnalité attendue par beaucoup de développeurs GWT. Lorsque l’on développe une application GWT, on se rend vite compte que le fichier JavaScript généré prend vite du poids. Cette fonctionnalité découpe l’application en plusieurs fichiers JavaScript qui seront chargés uniquement lorsque c’est nécessaire en rajoutant quelques lignes de codes.
Layout par contraintes
Beaucoup d’applications Web qui se basent sur JavaScript utilisent des widgets qui sont positionnées dans la page grâce à des calculs qui peuvent ralentir l’affichage de l’application.
À l’inverse, GWT 2.0 génère le rendu final en utilisant le CSS de la page, celui-ci est généré à la compilation et non plus pendant l’affichage de la page ce qui réduit considérablement le temps de chargement.
ClientBundle
Je présentais dans mon billet : Guide d’optimisation de vos applications Web une méthode pour réduire le temps de chargement d’une page en utilisant des images sprites.
GWT est capable depuis la version 1.4 de faire tout cela automatiquement grâce aux ImageBundle. Toutes les images référencées sur disque étaient réunies en une seule est GWT utilisé la technique des sprites pour afficher les images convenablement. Avec GWT 1.5/1.6, un projet de l’incubateur permettait de faire la même chose avec à peu près n’importe quels fichiers.
GWT 2.0 introduit cette notion avec les ClientBundle. Par exemple, vous pouvez références tous vos fichiers CSS, GWT va alors les regrouper en un seul fichier, le minimiser et le rendre disponible pour être mis en cache. GWT gère aussi l’internationalisation ainsi vous pouvez gérer vos ClientBundle pour chaque locale.
Speed Tracer
Cette nouvelle version sort avec une extension pour Google Chrome : Speed Tracer. Cette extension analyse l’exécution de l’application Web en cours. Plutôt que de longues explications, voilà la vidéo de présentation de Speed Tracer.
Présentation de Speed Tracer
Story of Your Compile
SOYC fournit de nombreux détails sur la compilation de chaque partie de l’application GWT : la taille, les dépendances, temps de compilation… Cela permet d’orienter ses efforts pour diviser le code grâce Code Splitting
Traces dans IE 6
Internet Explorer ne fournit pas les traces lorsqu’une exception JavaScript est levée, ce qui peut être très embêtant lors d’une phase de debug sur ce navigateur…
Avec GWT 2.0 vous obtenez maintenant la trace obfusquée (ou non en fonction de la compilation choisie) JavaScript qui peut être convertie en trace Java avec nom de classe et numéro de ligne.
Conclusion
Ce billet ne présente que les améliorations les plus importantes, mais il y à de très nombreuses évolutions : optimisation du compilateur, évaluation directe des réponses RPC (réduction du temps de déserialisation), propriété de deffered binding conditionnelles, …
GWT devient de plus en plus un framework “productif” : la plupart des problèmes qu’un développeur rencontre lors du développement d’une application Web qui utilise JavaScript, sont résolus très simplement.
Pensez-vous que cette version 2.0 de GWT va permettre au framework de gagner des parts de marché face à ses concurrents comme Flex?
Ruby on Rails : déployer une application sur Tomcat avec JRuby
7/09/09
Ruby on Rails est un framework qui permet de développer très rapidement des applications Web en suivant le modèle MVC.
Le problème de ce framework est qu’il se base sur le langage Ruby et qu’il embarque un serveur Web. Les applications ainsi créées ne peuvent pas être déployées comme des applications Web dans Tomcat ou autres serveurs d’applications.
Le but de ce tutoriel est de vous permettre de déployer les applications Ruby on Rails (RoR) sur un serveur Tomcat en utilisant la librairie JRuby.
Installation Tomcat
On commence par télécharger la dernière version de Tomcat (en ce moment c’est la version 6.0.20) :
1 2 | wget http://mirror.mkhelif.fr/apache/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.tar.gz tar –xzf apache-tomcat-6.0.20.tar.gz |
Voilà Tomcat est installé, je passerai ici la configuration du serveur. Si vous souhaitez, suivez mon tutoriel pour connecter Apache avec Tomcat.
Installation JRuby
Télécharger JRuby et placez le là où vous souhaitez :
1 2 3 | wget http://dist.codehaus.org/jruby/1.3.1/jruby-bin-1.3.1.tar.gz tar –xzf jruby-bin-1.3.1.tar.gz mv jruby-1.3.1 /usr/local/jruby |
Ajouter ensuite le chemin vers JRuby dans votre environnement en éditant votre fichier ~/.profile :
1 | export PATH=$PATH:/usr/local/jruby/bin |
Vous pouvez vérifier l’installation de JRuby en exécutant la commande suivante :
1 2 | $ jruby -v jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM) Client VM 1.5.0_16) [i386-java] |
Installation de Ruby on Rails
À partir de là nous allons installer les gems pour : rails (le coeur de ROR), mysql et surtout warbler (qui crée un WAR à partir de l’application rails).
1 2 3 | $ jruby -S gem install rails $ jruby -S gem install activerecord-jdbcmysql-adapter $ jruby -S gem install warbler |
Déploiement de votre application
Pour déployer votre application dans Tomcat, il faut commencer par la convertir en WAR. Placez vous dans le dossier de votre application et lancez la commande suivante :
1 | $ warble config |
Cela va créer un fichier <application>/config/warble.rb pour configurer votre application pour la convertir en fichier WAR, ouvrez le fichier et dé-commentez la ligne :
1 | config.gems += ["activerecord-jdbcmysql-adapter"] |
Cela pour inclure dans votre fichiers WAR la gem MySQL (ajoutez les gems que votre application utilise ici).
Maintenant nous allons créer le fichier WAR de votre application, lancez simplement la commande :
1 | $ warble |
Et voilà votre fichier WAR est créé, vous pouvez alors le déployer sur Tomcat (je passerai sur cette étape).
Tests en charge d’EC2, GAE et Azure
21/08/09
Lorsque vous démarrez un projet d’application Web qui sera déployée dans le cloud, on peut logiquement vouloir comparer les différents prestataires sur le marché. C’est ce qu’on fait des chercheurs Australiens en effectuant des tests en charge sur les plateformes EC2 d’Amazon, Google App Engine et Azure de Microsoft.
Le test consisté à une charge de 2000 utilisateurs simultanés, selon Anna Liu, les trois plateformes ont su se redimensionner avec la charge afin de répondre à la demande : “With a simulation of 2000 concurrent users, we watched the cloud services scale up and respond dynamically to that demand”.
Cependant les trois plateformes ont des temps de réponses variables, pouvant aller jusqu’à un facteur vingt, en fonction des fonctionnalités qui sont déployées par les prestataires ainsi que de l’heure à laquelle les utilisateurs accèdent aux services déployés.
Selon Liu, les trois plateformes ont des objectifs divergents : GAE est fait pour des applications Web simples et qui ne nécessitent aucun traitement long (une exception est lancée lorsque le temps de traitements de la requête dépasse trente secondes); EC2 propose les bases du cloud computing et la valeur ajoutée est fourni par des solutions tierces; Azure se limite uniquement aux applications .Net ce qui limite grandement les développeurs qui préfèrent se tourner vers d’autres solutions.
Toujours selon Liu, les plateformes manquent d’outils de monitoring inclus avec leur offre.
Source : http://www.itnews.com.au/News/153451,stress-tests-rain-on-amazons-cloud.aspx
Google : GWT version 1.6 et consorts
8/04/09
Ça y est, la version 1.6 officielle de GWT est enfin disponible après deux releases candidates (RC). Les nouveautés annoncées sont bien présentes. Parmi les nouveautés les plus importantes :
- Une refonte de l’architecture d’une application GWT pour qu’elle corresponde à celle d’un WAR. Cette nouvelle architecture est plus intuitive pour développer une application complète (testée avec le plugin Eclipse Cypal Studio).
- Une parallélisation du compilateur permet sur une machine multi-coeurs de diminuer sensiblement la durée de compilation. Maintenant, la compilation peut aussi être distribuée entre plusieurs machines.
- Une nouvelle approche de la gestion de événements par Handler. Pour avoir testé cette nouvelle implémentation, on se rapproche beaucoup plus de la gestion des événements Swing.
En marge de GWT, Google App Engine, la plateforme de déploiement des applications Web de Google, accepte désormais les applications Java dans un environnement Java 6. Cet environnement comprend les API suivantes : Java Data Objects (JDO), Java Persistence API (JPA) et JavaMail API.
Par ailleurs, Google a aussi développé un plugin Eclipse pour les développeurs GWT et Google App Engine. Ce plugin contient :
- Un assistant de création d’applications Web spécifique pour GWT ou Google App Engine.
- Un assistant de déploiement de votre application dans le cloud de Google.
- Une coloration syntaxique de votre code JSNI (JavaScript Native Interface). Très utile, surtout lorsqu’on à pris l’habitude de coder avec une coloration de commentaire…
Divers autres fonctionnalités sont disponibles avec ce plugin, mais je ne les ai pas encore testé.
Source : Introducing GWT 1.6 and friends.
GWT 1.6 : quoi de neuf ?
11/12/08
Ça y est la roadmap pour la version 1.6 de GWT a été publiée sur le blog officiel de GWT. Aucune date précise quand à la sortie de cette version, mais elle est annoncée pour le premier trimestre 2009.
Voilà les nouvelles fonctionnalités pour cette version :
- Nouvelle structure de déploiement : l’objectif étant de permettre un déploiement plus simple des WARs sur un serveur d’applications. Il s’agit surtout d’une restructuration dont voici la spécification.
- Jetty sera utilisé à la place de Tomcat (j’en parlais d’en un billet précédent). Une architecture plus modulable du hosted mode permettra de changer le serveur utilisé.
- Uniformisation des événements : les listeners actuels seront dépréciés et les nouveaux seront uniformisés pour tous les widgets.
- Intégration du DatePicker et du LazyPanel depuis l’incubateur GWT. Le DatePicker est comme son nom l’indique un widget permettant de sélectionner des dates (démo du DatePicker). Le LazyPanel permet de charger un composant uniquement lorsqu’on en a besoin (appel à la méthode setVisible (true)), ça permet de gagner du temps lors de l’initialisation de l’application.
- Optimisation des String : les StringBuilder seront optimisés pour chaque navigateurs grâce au deferred binding (optimisation à la compilation).
- Optimisation du compilateur GWT : réduction du temps de compilation.
Et celles qui sont prévues pour la suite :
- Découpage du code JavaScript généré en plusieurs fichiers. Le développeur pourra spécifier des points de césures qui permettront au compilateur de découper le code généré en plusieurs fichiers. Cela permettra évidemment d’éviter au client de télécharger toute l’application GWT en un seul fichier. Ceci lié au LazyPanel, les applications GWT devraient gagner en rapidité de chargement.
- Analyse du code compilé, appelée Story Of Your Compile (SOYC) : rapport permettant aux développeurs de savoir quelle classe génère le plus de code JavaScript.
- Sélection du navigateur à utiliser pour le hosted mode.
- Ui Binder : création des composants par déclaration, permet de séparer le layouting des composants (géré dans un fichier XML) de leur lien avec le modèle (géré dans le code Java).
- Client Bundle : généralisation du deferred binding (utilisé actuellement dans les Image Bundle) aux autres ressources statiques (css : CSSRessource, texte : TextRessource, image : ImageRessource).
- Optimisation du protocole RPC.
Oracle : faille critique dans WebLogic [corrigé]
30/07/08
Une faille critique vient d’être découverte dans le module mod_server, permettant la connexion de Apache à WebLogic (racheté à BEA par Oracle). Elle permettrait d’avoir accès à distance aux données du serveur sans aucune authentification.
Cette faille est notée comme très élevée (1.0 sur l’échelle CVSS Common Vulnerability Scoring System) et un correctif est déjà en préparation par Oracle.
Les versions de Oracle WebLogic Server affectées par cette faille sont : 6.1, 7.0, 8.1, 9.0, 9.1, 9.2, 10.0.
Voir le bulletin d’alerte de Oracle.
Mise à jour 08/08/2008 : Oracle a fourni un correctif à cette faille.
Commentaires récents