C’est le moment de passer à la deuxième partie de cette série sur HTML5, avec en ligne de mire les nouveautés côté JavaScript. La spécification a pris le parti de mettre JavaScript en avant, avec des API standards qui pourront être implémentées dans tous les navigateurs. L’un des buts de la spécification est de faire monter HTML et JavaScript à un niveau de finition et de performance égalant les applications de bureau. Côté performance, il y a le parallélisme et quelques fonctions natives qui viendront remplacer des fonctions déjà implémentées par les frameworks JavaScript. Mais HTML5 fait aussi écho à l’explosion du Web mobile avec la géolocalisation et les applications hors ligne pour ceux qui ne sont pas connectés en permanence.
Sommaire
Lire la suite de cet article »
Comme évoqué dans une précédente revue de presse, voici le premier article de ma série sur HTML5. Plutôt que de faire du comptage de points entre Apple et Adobe, j’ai décidé de commencer par faire un tour d’horizon des nouveautés proposées par cette nouvelle spécification du W3C. Dans ce premier article, je vous propose donc de faire un voyage à la découverte des nouveautés du côté de HTML. ; pour connaître les nouvelles balises, et les nouveaux attributs que nous pouvons déjà ou pourrons bientôt utiliser dans nos navigateurs. Du layout au canvas en passant par les WebForms, le son et la vidéo, tout tout tout, je vous dirai tout sur HTML5. Commençons donc par le commencement: HTML5 qu’est-ce que c’est ?
Sommaire
Lire la suite de cet article »
Dans notre article sur l’utilisation de HTTPS avec Tomcat en production, nous avons étudié les solutions reposant sur la mise en place d’un reverse proxy HTTP. Nous n’avons pas oublié pour autant le protocole AJP. Ce protocole est né pour faciliter et accélérer les communications entre un serveur web frontal et le serveur d’application JServ en back-end d’Apache. Avec le temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu’en 2003, AJP était la seule solution viable permettant de placer le serveur d’application derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans Apache est née la solution tout HTTP. Nous avons donc décidé d’organiser un match opposant la solution AJP à la solution HTTP.
Lire la suite de cet article »
Suite à vos retours nombreux, aux différents articles touchant à la sécurisation par SSL de Tomcat en production (Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header HTTP X-Forwarded-For, Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS), nous commençons une série sur Tomcat en production.
Dans ce premier article, nous abordons l’utilisation de SSL pour sécuriser les communications. Pourquoi utiliser SSL ? Comment SSL est-il intégré avec le moteur de Servlet ? Et surtout quelle configuration correspond à votre application, qu’elle soit hébergée sur un serveur Tomcat seul, avec un serveur Apache Httpd en frontal, avec un accélérateur SSL ou avec un load-balancer hardware.
Lire la suite de cet article »
Configurer Tomcat 5 derrière un proxy Apache avec HTTPS, dit comme ça, le novice éclairé pourrait croire que c’est facile. Cependant les problèmes dus à de mauvaises configurations sont nombreux et parfois difficiles à diagnostiquer comme les boucles infinies de redirection par exemple. Donc facile oui (maintenant), mais il m’a fallu plusieurs heures de sueur avant de trouver, non pas une, mais deux solutions. L’avantage de ces deux techniques est de n’utiliser que le driver SSL d’Apache pour fournir le protocole HTTPS. Notez bien cette distinction, car il est facile d’avoir la configuration Apache HTTPS en proxy de Tomcat 5 HTTPS. Toute la difficulté est d’avoir une configuration pleinement fonctionnelle dans laquelle Apache HTTPS est proxy de Tomcat 5 HTTP. Cela permet de sniffer les paquets entre le frontal Web et l’application métier, tout en évitant de doubler les ressources utilisées pour encrypter et décrypter les données.
Un détail pour ceux qui utilisent le mod_jk, le projet Apache Httpd propose depuis Apache 2.0, le module mod_proxy qui permet notamment d’assurer la liaison Apache-Tomcat. Ce module, complété en version 2.2 de mod_proxy_balancer pour le load balancing, supporte les protocole HTTP (mod_proxy_http) et AJP 1.3 (mod_proxy_ajp). Si AJP a longtemps été le protocole utilisé par Tomcat en production, il est aujourd’hui possible, plus simple et plus fiable d’utiliser HTTP. HTTP est notamment recommandé par Mark Thomas et Philip Hanik, SpringSource, qui sont les plus gros contributeurs du projet Tomcat en ce moment.
Si vous êtes habitués à mod_jk, vous apprécierez notamment la simplicité d’un module embarqué par la distribution standard de Tomcat, la fin des interrogations sur la fermeture des connexions en présence d’un firewall entre Apache et Tomcat ou encore le débuggage avec un sniffeur réseau comme wireshark pour voir passer en clair les requêtes HTTP.
Lire la suite de cet article »
Mettre au grenier la configuration XML et l’API J2EE, voilà le pari que tentent de relever les frameworks orientés composants. Pour atteindre ce but louable : simplifier la vie stressée du développeur et par là même sauver quelques-uns de ses cheveux, le XML est remplacé par du code Java et l’API J2EE est cachée dans les entrailles du framework. Les pages deviennent des objets Java liés à des templates, auxquels sont ajoutés des composants réutilisables (si, si). Les composants sont ni plus ni moins que d’autres objets Java liés à des templates. Les requêtes, quant à elles, deviennent des événements traités par les pages et les composants.
Voilà pour le principe de cette approche qui semble avoir de beaux jours devant elle. Emergence naturelle ou stratégie voulue, la fondation Apache, jamais avare de solutions, nous propose deux frameworks composants : Tapestry 5 et Wicket. Alors comment choisir ? Le mieux est encore de se faire sa propre idée en les testant tous les deux. Nous sommes bien d’accord, rien ne remplacera jamais l’efficacité du prototypage. Cela n’empêche pourtant pas de faire une pré-sélection basée sur quelques points de comparaisons stratégiques. Voici donc un article pour vous aider à faire le meilleur choix ; à savoir le choix qui répondra le mieux aux besoins et à l’environnement de votre projet.
Bien qu’adoptant tous deux la programmation web orientée composant, les deux projets sont imprégnés d’une philosophie et d’un objectif différents. Les buts principaux de Wicket sont :
- Pages et composant statefull
- Programmation à la Swing
- Séparation stricte entre code et template
Pour Tapestry 5, les objectifs sont différents :
- Optimiser l’utilisation CPU et mémoire
- Simplifier la création de composants
Attention ! Ce sont là les objectifs sur lesquels les deux projets sont focalisés. Ce qui ne signifie pas qu’ils s’y intéressent exclusivement. Wicket supporte bien les composants sans état, ce n’est juste pas son but principal. De même que Tapestry supporte le développement web entièrement en objet Java.
Ils affichent, aussi, des buts communs, comme d’être orientés Pojo et d’éliminer la configuration XML avec le pattern Convention Over Configuration.
Lire la suite de cet article »
Quand on parle d’injection de dépendances, on pense tout de suite à Spring qui se tient sous les feux de la rampe. On peut aussi penser au petit dernier Guice abordé dans l’article Google Guice 2 : Les bases de l’injection de dépendances. Mais il ne faudrait pas oublier Tapestry 5 qui, lui aussi, fournit sa solution pour l’injection de dépendances. Tapestry IoC, à ne pas confondre avec le framework de développement Web Tapestry 5, est très fortement inspiré de Guice. Son but affiché est de tirer le meilleur de Guice tout en apportant l’héritage de son grand frère défunt Hivemind. On garde donc l’objectif zéro XML en le remplacant par du code Java. Parmi les avantages de cette technique, on citera :
- Le démarrage d’une application est plus rapide avec une configuration IOC en annotations Java qu’avec une configuration XML à parser
- On peut tester unitairement les modules d’injection puisqu’il s’agit de classe Java simple
- Finie la configuration laborieuse en XML
J’ai même envie de rajouter que l’apprentissage d’une API Java est bien plus rapide que celui d’une syntaxe XML. Tout comme Guice, Tapestry IoC se concentre sur l’injection de dépendances et ne tente pas de fournir une stack complète de développement comme le fait Spring. On ne trouve ni les Aspects, ni le pattern Template cher à Spring. Pour répondre aux besoins de programmation par aspect, Tapestry IoC propose des interceptors qui peuvent décorer les services. D’autre part, dans Tapestry IoC, l’injection est définie dans un ou plusieurs module(s) chacun d’eux pouvant contribuer à la configuration et aux services de l’application.
Dans ce premier article de la série Tapestry 5 qui commence aujourd’hui, nous verrons les bases de l’injection avec Tapestry IoC et les différences par rapport à Spring et Guice.
Lire la suite de cet article »
Quartz pour ceux qui ne le connaissent pas encore, est un ordonnanceur. Il permet de planifier des tâches pour des exécutions ponctuelles ou répétées. Les planifications possibles vont de la simple répétition infinie, à la répétition calendaire utilisant la syntaxe de cron (tous les jours à minuit, le 31 janvier 2009 à 12h00, …). Quartz est prévu pour toutes sortes d’applications allant des programmes standalone basiques aux gros systèmes JEE distribués.
De son côté, Spring scheduling nous donne le choix entre les Timers Java et Quartz. Avec ses interfaces, Spring nous permet de planifier, très facilement, des Jobs directement dans l’ApplicationContext. En revanche, la gestion des planifications dynamiques est moins évidente. Dans cet article, je vous présenterai l’API Quartz dans les grandes lignes, puis on mettra en place la planification Quartz avec Spring Scheduling.
Lire la suite de cet article »
Dans un projet J2EE, il est toujours utile de pouvoir déployer son application sur un serveur et plus encore pour faire de l’intégration en continu avec des tests fonctionnels. La plupart du temps, on utilise un serveur dédié pour les tests et les outils livrés avec pour gérer les déploiements.
Cargo utilise les outils de chaque serveur et livre une interface unifiée pour administrer les serveurs J2EE. En bref, Cargo permet d’installer, de configurer, de lancer et d’arrêter des serveurs dans une approche multi-conteneurs. De plus, on peut enfin l’utiliser à travers plusieurs outils, puisqu’il fournit des extensions pour Netbeans, Ant, IntelliJ, Maven 1 et 2, et bien sûr une API java.
Dans cet article, nous présenterons d’abord Cargo et son fonctionnement, puis un exemple concret d’intégration continue dans un projet Maven avec Cargo et Selenium.
Lire la suite de cet article »
Nous avons déjà abordé le sujet en surface lors du précédent article « introduction à Json » ; voici une présentation du framework JavaScript Prototype.
Depuis l’avènement d’Ajax, de multiples framework JavaScript sont nés dans le but de faciliter les développements JavaScript, et d’assurer une meilleure maintenabilité des scripts. Il faut bien reconnaître que le côté langage de script joue traditionnellement en la défaveur de JavaScript.
Mais aujourd’hui, il est possible d’envisager les choses autrement. Nous verrons dans cet article comment :
- Utiliser les classes et l’héritage.
- Simplifier les manipulations DOM.
- Gérer mieux les événements.
- Faire des requêtes Ajax.
Lire la suite de cet article »
Complet
Twitter
