Formation, conseil, accompagnement Java

Administration WildFly

Alexis Hassler — 2013-04-19T18:53:54Z

WildFly est le nouveau nom de JBoss AS. Mais, pour l'instant aucune release n'a été faite sous ce nom.

Pour suivre une formation sur la dernière version de JBoss AS, vous devrez vous contenter de la formation Administration JBoss AS 7.

Programme du cours

A venir, quand WildFly sera sorti...

JBoss AS7 en cluster

Alexis Hassler — 2013-02-01T20:39:31Z

JBoss AS est le leader des serveurs applicatifs Java EE libres et de plus en plus d'entreprises le choisissent au détriment de ses concurrents propriétaires.

Ce cours avancé s'adresse à tous ceux qui souhaitent mettre en place un environnement JBoss AS 7 en cluster. Les différents types de réplication et de répartition de charge sont abordés, sur les aspects HTTP, EJB et JMS. A chaque étape, un atelier vous permet de mettre la théorie en pratique. A la fin du cours, vous aurez les armes pour déployer des applications Java EE avec un haut niveau de disponibilité et une bonne scalabilité.

Introduction

Concepts du clustering
Quelques définitions : scalabilté, membership, farming, failover, ...
Typologie des clusters
Répartition de charge contre haute-disponibilité

Fonctionnalités de clustering de JBoss AS 7
Les sous-systèmes impliqués dans le clustering
Les mécanismes de répartition
La réplication des objets à état
Clustering vertical contre clustering horizontal
Les configurations prédéfinies dans JBoss AS 7
L'administration en domaine

Communication entre nœuds avec JGroups
Rappels réseau : IP, TCP / UDP, multicast / unicast
Les canaux et piles de protocoles
Les protocoles présents dans les configurations par défaut de JBoss
Les principaux paramètres de configuration

Répartition HTTP

Apache en distributeur de charge
Comment éviter le Single Point of Failure ?
Choix entre une répartition HTTP et un distributeur matériel
Les techniques de répartition Apache : mod_jk, mod_proxy, mod_cluster

La solution JBoss : mod_cluster
Les différents modules Apache
La configuration dans JBoss AS
La configuration coté Apache
Le calcul de charge des nœuds
La gestion via JBoss CLI

Réplication de sessions HTTP

Cache distribué avec Infinispan
Les types de distribution et de réplication supportés par Infinispan
La notion de cache-container
Les options de synchronisation : concurrence et isolation
Adaptation de la pile JGroups en fonction du type de réplication
Monitoring d'Infinispan

Réplication de session HTTP
Réplication ou distribution ?
Les Configurations par défaut
Les descripteurs de déploiement Web

Clustering d'EJBs

EJBs session
Rappels sur la configuration des pools
Les algorithme de répartition de charge
EJBs distants / EJBs locaux
Répartition de charge des EJB stateless
Répartition de charge et synchronisation des EJB stateful
Configuration par défaut d'Infinispan

Entités JPA
Infinispan et l'invalidation
Le cache de second-niveau d'Hibernate
Configuration par défaut de JBoss
Les annotations spécifiques Hibernate

Clustering JMS

Fonctionnalités HornetQ
Groupe de serveur
Découverte automatique
Répartition de charge
Répartition des connexions clientes
Redistribution de messages

Clustering HornetQ
Configuration prédéfinies Jboss
Mise en place de la redistribution
Usine à connexions HA
Mise en place de serveurs de backup
Clients JMS d'un cluster

A chaque étape, les stagiaires mettent en œuvre les techniques présentées, en déployant des applications JavaEE et en intervenant dans les différents réglages de JBoss AS. Les exercices pratiques sont réalisés avec le JDK 6 et JBoss AS 7 sous Windows, Linux ou MacOS.

JBoss AS 7 pour développeurs

Alexis Hassler — 2013-01-02T10:14:41Z

JBoss AS 7 apporte avant tout le support du standard JavaEE 6, pour lequel elle est certifiée. Du point de vue de son utilisation, les changements par rapport aux versions précédentes sont radicaux : fichiers de configuration, console, interface en ligne de commande et surtout système de modules.

Grâce à ce cours, vous connaîtrez les procédure élémentaires de l'administration de JBoss AS 7, vous saurez l'intégrer dans votre environnement de développement et vous connaîtrez les impacts qu'il peut provoquer sur votre architecture.

Programme du cours

Bases de l'administration de JBoss AS
Présentation de JBoss AS (sous son nouveau nom) et JBoss EAP
Installation, démarrage et arrêt
Installation depuis les sources

Configuration standalone
Mode autonome ou domaine
Principaux éléments de configuration
Configuration réseau

Déploiement d'applications et de modules
Déploiement d'applications (ear, war, jar,...)
Déploiement automatique ou manuel
Gestion des dépendances avec les modules
Impact des modules sur les versions des librairies
Exemples de mise en oeuvre : JSF, Hibernate, outils de logs, datasources
Déploiement de DataSource
Déploiement de destinations (Queue et Topic)

Gestion des traces
Introduction
Traces du serveur
Traces des applications avec Log4J ou SLF4J ; gestion des versions avec les modules

Outils d'administration
Console d'administration
Commandes par script
Outils du JDK (jconsole, visualvm)

Environnement de développement
Intégration dans Eclipse
Utilisation du repository maven de JBoss AS 7
Intégration du repository maven de JBoss EAP 6
Déploiement depuis Maven

Migration depuis d'autres serveurs d'applications
Du classpath aux modules
JPA : persistence.xml, JPQL
Changement des noms JNDI
Accès distant aux EJB

A chaque étape, les stagiaires mettent en œuvre les techniques présentées, en déployant des applications JavaEE et en intervenant dans les différents réglages de JBoss AS.

Les exercices pratiques sont réalisés avec le JDK 6 et JBoss AS 7 sous Windows, Linux ou MacOS, en utilisant Eclipse ou IntelliJ.

Play ! Framework

Alexis Hassler — 2013-01-01T16:27:52Z

Les développeurs Java ont tendance à rechercher la complexité, là où d'autres cherchent l'efficacité. Play ! Framework a pris le contre-pied de cette culture en mixant la puissance de Java avec une productivité optimale.

Au cours de cette formation, vous découvrirez la philosophie et les concepts de Play ! Framework, puis vous apprendrez, pas à pas, à les mettre en œuvre. L'essentiel de la formation vous fera évoluer avec la version 1.2 ; dans la dernière partie vous apprendrez comment développer avec la version 2.

Programme

Les concepts de Play ! Framework
Les choix d'architecture : MVC et stateless
Play ! Framework et ses concurrents
Les deux versions de Play

Premiers pas : créer sa première application
L'installation de Play ! Framework
L'utilisation en ligne de commande
L'intégration dans l'IDE
Comment debugger l'application ?
Première synthèses : la structure de l'application

Développer le modèle
La persistence avec JPA
Les tests unitaires du modèle
La gestion des transactions

Développer le contrôleur
Les classes et méthodes de contrôle
La construction des réponses HTTP
Le binding entre objets et information affichées ou saisies
La validation des informations saisies
Les portées Flash et Session

Développer la vue
Le templating
Les balises personnalisées (custom tags)
L'intégration avec Javascript / Ajax
L'intégration avec les frameworks CSS (LESS, bootstrap)
L'internationalisation i18n

La gestion du routage
Introduction à REST
Naviguer dans l'application
Associer les ressources aux URLs
La négociation de contenu

Les techniques avancées de tests
Les tests unitaires
Le développement de fixture
L'utilisation de Sélénium

Les modules indispensables
Comment sécuriser l'application ?
Le module d'administration
Le moteur de recherche
La génération de documents PDF

La préparation pour la mise en production
Configurer l'application
La gestion des dépendances et la résolution des conflits
Le déploiement autonome ou dans un serveur d'applications
Organiser les évolutions de la base de données
Le déploiement dans le cloud

L'évolution avec Play ! 2
Développer en Scala ou Java ?
Les évolutions structurelles : build SBT, persistance avec Anorm et Ebean
La programmation événementielle (Iteratee, Enumerator)
Une première application Play ! 2.0

Des exercices pratiques permettent d'illustrer les différents sujets abordés dans le cours. Ils sont réalisés avec Eclipse, Netbeans ou IntelliJ IDEA.
Plus de détails sur les environnements de TP...

Sorties de l'été 2011, JBoss AS 7

Alexis Hassler — 2011-10-07T14:15:30Z

Dans notre dernier article, nous avons évoqué les deux sorties majeures de l'été 2011 : JavaSE 7 et JBossAS 7. Nous avions détaillé le contenu de JavaSE 7, voyons maintenant ce que la sortie de JBossAS 7 peut nous apporter.

Nous commencerons par les nouveautés les plus visibles comme l'allègement de la plateforme et la réduction du temps de démarrage, puis nous aborderons les évolutions plus profondes comme le nouveau système de modules. Enfin, nous parlerons un peu de Cloud.

JavaEE 6

JavaEE 6 est une version assez importante dans l'histoire de JavaEE parce que c'est la première qui peut réellement être compétitive vis-à-vis de Spring Framework. En particulier, CDI apporte un mécanisme d'injection universel qui manquait à JavaEE. Ajoutez à cela des simplifications au niveau des architectures et des modèles de développement et on a une technologie plutôt souple et pratique à utiliser. Encore faut-il que les serveurs d'applications qui implémentent cette spécification soient au même niveau...

JBoss AS 6 implémentait déjà JavaEE 6, sans être certifié. JBoss AS 7.0 implémente le Web Profile, et est même certifié. Il implémente aussi partie du Full Profile, mais il faudra attendre JBoss AS 7.1 pour avoir un vrai Full Profile.

Historique

L'aventure de JBoss a commencé en 1999. L'organisation du projet était basée sur l'open source dès le début.

Je n'ai pas cité la version 1 parce que je n'en ai pas trouvé de trace et qu'à titre personnel, j'ai directement commencé avec la version 2. On voit une progression régulière des versions majeurs jusqu'en 2004. A noter que cette année-là, la version 4.0 était la première version certifiée chez JBoss. Ensuite, un gros trou... Puis une version 4.2, dont le but était de nous apporter une implémentation partielle de JavaEE 5 et de nous faire patienter avant la version 5.0 qui devait être certifiée JavaEE 5. Pourquoi un tel délai ? Il y a probablement plusieurs raisons. Tout d'abord techniques. Le noyau a été réécrit, pour pouvoir gérer des composants internes de granularité plus fine. Ensuite, JBoss a été rachetée par RedHat, ce qui a probablement déstabilisé les équipe et eu une influence sur leur organisation... Toute ressemblance avec les versions d'un JDK ayant existé est fortuite... Toujours est-il que cette version 5 a traumatisé pas mal de monde. C'est probablement la version la plus utilisée aujourd'hui.

La version 6 qui a suivi est basée sur la même architecture que la 5, mais implémente JavaEE 6, sans être certifiée. Un nouvelle version d'attente, semble-t-il. Et cette année, cette version 7 est sortie, complètement différente des précédentes. Je peux dire sans problème que la version 6 ressemble plus à la v 2 qu'à la v 7.

Architecture

JBoss AS 7 est consitué d'un noyau, appelé core infrastructure et de composants, appelés subsystems. Ces composants sont souvent issus de projets autonomes, comme Hibernate, Weld, HonertQ ou Infinispan.

En comparaison avec un JBoss AS 6, il n'y a aucun changement fondamental. Le noyau s'appelait micro container et les composants étaient des services. On retrouve Hibernate, Weld, HonertQ et Infinispan.

Le changement n'est donc pas dans les composants utilisés, mais dans le noyau. On ne va pas détailler toutes les parties de l'infrastructure, mais on peut parler du système de threading qui permet des gains de vitesse, en particulier au démarrage et au déploiement, ou de modules qui devrait rationaliser la gestion du classpath.

Légèreté

Le premier effet de ce changement est la réduction du temps de démarrage. Sur mon poste de travail, un laptop core2 duo, on est passé de 45 secondes à 3 secondes !

En mesurant cette valeur pour les versions précédentes, on constate que la version 5 a été une vraie régression sur ce plan. A l'époque, l'équipe de JBoss était plus concentrée sur la robustesse que sur l'agilité, plus sur l'environnement de production que sur le développement. Et, alors que JBoss avait commencer par séduire les développeurs, il s'est éloigné de ce chemin.

En 2009, dans le comparatif sur les temps de démarrage fait par Antonio Goncalves, JBoss était le plus mauvais ; Même derrière Websphere. Glassfish était en tête. En fait, le temps de démarrage n'était tout simplement pas considéré comme une une fonctionnalité par l'équipe de développement de JBoss alors qu'il faisait partie des priorités chez Glassfish.

On voit bien que les choses ont changé puisqu'aujourd'hui, il y a une page dédiée aux records de démarrage sur le wiki de JBoss. Le record est inférieur à une seconde. L'amélioration du temps de démarrage est pas mal lié au nombre de processeurs parce que JBoss utilise pas mal la mise en parallèle des tâches.

Le deuxième point d'allègement est la mémoire. J'ai mesuré ici la mémoire heap utilisée après le démarrage. On voit aussi que la situation s'est nettement dégradée avec la version 5 et a été drastiquement améliorée avec la v7.

Enfin le dernier point d'allègement est le nombre de fichiers XML utilisés pour la configuration. On passe de 150 à un seul, ou presque. On dit d'ailleurs que le temps de parsing XML de JBoss AS 5 ou 6 est supérieur au temps complet de démarrage de JBoss AS 7.

Ça améliore donc les temps de démarrage, mais surtout, ça nous facilite la vie. Fini le labyrinthe pour trouver le bon répertoire puis le bon fichier, puis le bon bean dans le fichier. Tout est centralisé dans un seul fichier, avec une structure de répertoire plus simple.

Déploiement

Pour le déploiement d'applications. ça ressemble a priori aux anciennes versions : on dépose une archive et quelques secondes plus tard, elle est déployée. La nouveauté, c'est que ce mode automatique est désactivé par défaut pour le déploiement en répertoire ; il n'est activé que pour le déploiement en archive. C'est plutôt une bonne nouvelle car comment JBoss peut-il savoir que la copie du répertoire est terminée, en particulier depuis wue le fichier web.xml d'un war est facultatif ?

En regardant de plus prêt, on constate que le cycle de déploiement est un peu plus complexe, avec plus d'états intermédiaires. Ces états sont marqués sous forme de fichiers marqueurs dans le répertoire de déploiement. Par exemple, si un déploiement échoue, il est marqué en .fail ; et tant que le fichier .fail sera présent, JBoss n'essaiera pas de redéployer.

En déploiement manuel, on utilise aussi ces fichiers pour déclencher le déploiement. JBoss n'essaie pas de déployer l'archive ou le répertoire déposé, il ne le fera que lorsqu'il verra le fichier .dodeploy.

Administration

Du coté des outils d'administration, ça a bien changé aussi. On se rappelle de jmx-console et de twiddle, outils certes puissants pour interroger le serveur d'applications, mais très peu ergonomiques, complexes à appréhender et inutilisables pour configurer du fait que leurs effets n'étaient pas persistants. Dans JBoss AS 7, on a une nouvelle console, une nouvelle interface en ligne de commande, une interface en HTTP / JSON et une API Java d'administration.

La console d'administation n'a peut-être pas la richesse de celles des concurrents, mais elle est utilisable, voire pratique à utiliser. On peut y faire les opérations classiques d'administration : créer des datasources, reconfigurer les logs, déployer à distance, reconfigurer les interfaces réseau... Certes, l'admin-console d'AS 5 et 6 permettait de faire tout ça, mais avec des lenteurs et une ergonomie exécrables. Et en bonus par rapport à l'admin-console, on peut consulter le contenu JNDI !

La commande jboss-admin fournit le même niveau de fonctionnalités, mais en ligne de commande. Son fonctionnement est plutôt agréable : une fois l'outil lancé, on navigue de façon interactive dans la configuration, à la façon d'un système de fichiers. On retrouve d'ailleurs certaines commandes des systèmes Unix : cd, ls, pwd. Puis sur les noeuds de la configuration, on peut lire le contenu et le modifier.

JBoss AS 7 expose les mêmes fonctionnalités d'administration via une interface HTTP / JSON et via une API Java.

JBoss Module

Avec les serveurs d'applications, et particulièrement avec JBoss, les prises de tête avec des ClassNotFoundException, des NoClassDefFoundError ou des ClassCastException sont monnaie courante. Sans compter l'enfer pour faire cohabiter des versions différentes d'une librairie. Un ancien collègue m'a même dit un jour : "La fonction principale des classloaders dans JBoss, c'est de faire vivre des consultants". Tout ça, c'est dû au classloader et au classpath... qui serait mort, selon les dires de Mark Reinhold, à JavaOne 2009.

Le classpath ne pourra réellement mourir que lorsque JavaSE 8 sera sorti, avec Java Module, issus du projet JigSaw. Et ceci ne devrait pas arriver avant l'été 2013. En attendant, OSGi fournit ce type de fonctionnalités, mais avec bien d'autres choses. Pour JBoss AS 7, l'équipe a choisi de développer sa propre solution appelée JBoss Module.

Domaine

Depuis toujours, la configuration de JBoss AS était gérée individuellement. La gestion centralisée n'était possible que par l'ajout d'un outil tiers comme RHQ ou JON. Avec AS 7, JBoss a introduit les notions de domaine et de groupe de serveurs.

Un domaine est un ensemble d'instances dont l'administration est centralisée. Sur chaque serveur physique, une instance joue le rôle de host controller alors qu'une seule instance de l'environnement joue le rôle de domain controller.

Un server group est un ensemble de serveurs qui ont la même configuration et qui sont mis à jour simultanément par le domain controller.

Cloud Computing

Avec ses caractéristiques, JBoss AS 7 semble naturellement taillé pour le cloud. Avec son offre PaaS OpenShift, RedHat nous le confirme immédiatement. L'offre s'articule en deux partie :

Express, dans laquelle on n'a aucune action sur JBoss ; on ne peut que déployer du code source par une commande git push, le build étant fait pas le serveur.

Flex, qui fournit l'outillage pour gérer nos instances de JBoss sur un environnement Amazon AWS.

Cette offre a rapidement été concurrencée par CloudBees qui a annoncé l'intégration de JBoss AS 7 dans son offre RUN@cloud.

Conclusion

La version 7 de JBoss AS est une vrai révolution par rapport à toutes les versions précédentes. Même si beaucoup de composants sont inchangés, toutes les pratiques de configuration et d'administration sont à revoir. Par ailleurs, le changement de mécanisme de chargement de classes peut rendre douloureuses certaines migrations. Mais l'investissement sera vite rentable, toutes vos équipes apprécieront la nouvelle version.

En revanche, pour les personnes qui ont l'habitude d'utiliser Glassfish 3, cette version paraîtra beaucoup moins révolutionnaire. On peut même dire que JBoss AS 7 ressemble plus à Glassfish qu'aux anciens JBoss !

En complément de cet article, vous pouvez aussi consulter les slides que j'ai utilisés lors de ma présentation de JBoss AS 7 à SoftShake 2011 :

Enfin, Sewatech propose une formation à l'administration de JBoss AS 7, disponible dès janvier 2012.

Administration JBoss AS 7

Alexis Hassler — 2011-10-02T14:14:29Z

JBoss AS 7 apporte avant tout le support du standard JavaEE 6, pour lequel il est certifié. D'un point de vue administration, les changements par rapport aux versions précédentes sont profonds : modification complète des fichiers de configuration, nouvelle console, nouvelle interface en ligne de commande, nouveau système de modules,...

Ce cours commencera par vous montrer en quoi JBoss AS 7 fait partie des serveurs d'applications modernes. Il vous permettra de comprendre le fonctionnement et les principes de configuration de JBoss AS 7 . Il vous permettra d'acquérir les pratiques nécessaires à son administration (déploiement, logging, monitoring, sécurité...). Vous étudierez les leviers qui permettent d'obtenir la qualité de service attendue pour vos applications.

Grâce à cette formation vous comprendrez aussi la politique de versionnage de JBoss et vous saurez comment obtenir la toute dernière version de JBoss AS 7, même s'il faut la compiler soit-même.

Programme du cours

Introduction à JavaEE
Présentation de Java et de JavaEE
Typologie des applications JavaEE
Profils de JavaEE 6

Bases de l'administration de JBoss AS
Présentation de JBoss AS, WildFly et JBoss EAP
Installation, démarrage et arrêt
Installation en service
Compilation et installation depuis les sources

Configuration standalone
Mode autonome ou domaine
Principaux éléments de configuration
Configuration réseau

Déploiement d'applications et de modules
Déploiement d'applications (ear, war, jar,...)
Déploiement automatique ou manuel
Gestion des dépendances avec les modules
Déploiement de DataSource

Administration d'un domaine JBoss AS
Introduction au mode domaine
Configuration d'un Host Controller
Configuration d'un Domain Controller en domaines
Déploiement d'applications en domaines

Gestion des traces
Introduction
Traces de la JVM
Traces d'accès Web
Traces du serveur
Traces des applications avec Log4J ou SLF4J

Inspection du serveur
Outils JBoss
Console d'administration
Commandes par script
Outils du JDK
Supervision avec RHQ / JOPR

Amélioration des performances
Tuning de la machine virtuelle
Gestion de la mémoire et du Garbage Collector
Dimensionnement des pools (EJB, DataSource, threads)
Performances JPA

Sécurité du serveur et des applications
Objectifs de sécurisation du serveur
Sécurisation des interfaces d'administration
Gestion des autorisations et des authentifications en JavaEE (JAAS)
Sécurisation des applications
Sécurisation des échanges avec SSL

Administration JMS
Principe de JMS
Déploiement de destinations (Queue et Topic)
Accès à la ConnectionFactory
Configuration de JBoss HornetQ

(en option, 1 journée) Clustering JBoss
Objectifs du clustering : tolérance de panne (failover) et à la répartition de charge (load balancing)
Répartition des invocations EJB
Répartition des requêtes HTTP
Synchronisation des états
Répartition de la charge JMS avec HornetQ
Tolérance de panne JMS avec HornetQ

A chaque étape, les stagiaires mettent en œuvre les techniques présentées, en déployant des applications JavaEE et en intervenant dans les différents réglages de JBoss AS.

Les exercices pratiques sont réalisés avec le JDK 6 et JBoss AS 7 sous Windows, Linux ou MacOS.

Sorties de l'été 2011, Java SE 7

Alexis Hassler — 2011-08-15T13:44:07Z

Au cours de cet été 2011, deux événements m'ont marqué : la sortie de Java SE 7 et celle de JBoss AS 7. Tous deux sont suffisamment importants pour faire l'objet d'articles séparés. Nous commençons donc par la sortie de Java SE 7.

Dans cet article, nous nous concentrons sur les modifications du langage qui concerne directement le développeur : l'opérateur en diamant, le multi-catch d'exceptions, le try-with-resources,...

Versions de Java

Commençons par un petit historique des versions de Java et de Java SE.

La première chose qu'on constate, c'est le ralentissement du rythme des sorties. Les cinq premières versions étaient livrées tous les dix-huit mois, avec parfois des versions mineures intermédiaires. C'était aussi le temps des acrobaties marketing ; Java 2 SE version 1.4.2, c'est franchement mauvais en terme de lisibilité.

La version 5 a marqué un véritable tournant. Pour le nom, déjà : on passe de J2SE à Java SE ; fini le 2 sans signification. Fini aussi le 1.x ; vus les changements entre la 1.0 et cette potentielle 1.5, une version 2 aurait été un langage totalement différent ; autant changer de nom dans ce cas. Finies aussi les versions mineures. Il n'y aura pas de version 5.1. Enfin sur le contenu, cette version 5 a été très importante pour rendre le langage Java plus pratique. On se rappellera que les generics, les types Enum et les annotations datent de cette version.

La suite est moins enthousiasmante. Deux ans pour une version 6 sans grand relief, puis le silence. Quatre ans et demi sans nouvelle version ! Plusieurs causes se cumulent pour expliquer ce délai. La première est la mise en open source du JDK, avec le démarrage du projet OpenJDK peu de temps après la sortie de la version 6. Ce projet s'est accompagné d'un changement de politique entre le JDK et la spécification. Dorénavant, le développement public du JDK précède la rédaction de la spécification. Enfin, dernière explication, et pas des moindres, le rachat de Sun Microsystems par Oracle et le délai imposé par l'Union Européenne pour son enquête. Celle-ci concernait une éventuelle position dominante dans le domaine de la base de données, mais a beaucoup affecté l'évolution de Java.

Finalement, cette version 7 est là et c'est certainement le plus important, probablement plus encore que son contenu. Java is moving forward, et j'ajouterais again.

Nouveautés de Java 7

Il existe un nombre important d'articles traitant des nouveautés de Java SE 7. Ne vous enthousiasmez pas trop en les lisant car certains se basent sur les prévisions initiales de Sun qui ont été remises en question en 2010, dans le plan B d'Oracle. Celui-ci avait pour objectif de livrer une version moins ambitieuse mais suffisamment intéressante dans un délai raisonnable. Pour cela, des fonctionnalités majeures ont été reportées à la version 8 ou à plus tard encore. Donc si vous lisez un article vous présentant les closures ou la modularité en Java SE 7, vous risquez d'être déçu...

Donc pour résumer, les principales nouveautés du langage dans Java SE 7 sont :

l'opérateur en diamant,
le support des String par les switch / case,
la mise en forme des valeurs littérales,
le multi-catch d'exception,
le try-with-resource.

Toutes ces nouveautés viennent du projet Coin. On trouve aussi de nouvelles API comme NIO2 et fork / join, des changements de plus bas niveau, au niveau de la sécurité et avec la nouvelle instruction InvokeDynamic, et quelques modifications mineures.

Opérateur en diamant

Cette nouvelle notation permet d'alléger le code lorsqu'on instancie une classe avec generic. Le cas classique est celui des collections :

 List<MyClass> maListeOld = new ArrayList<MyClass>() ;

Le type contenu dans la liste est répété entre la déclaration et l'instanciation. L'opérateur en diamant évite cette redondance :

 List<MyClass> maListeNew = new ArrayList<>() ;

Les esprits chagrins prétendent que ça ne sert à rien puisque leur IDE préféré leur évite de réécrire le contenu. Mon avis est que c'est encore un cas où l'IDE servait à combler une lacune du langage, comme c'est souvent le cas.

Cette évolution est légère mais sera très souvent utile.

Strings in switch statements

Dans un premier temps, seuls les types entiers (byte, short, int, long, char) pouvaient être utilisés dans les switch, sous forme littérale ou par l'intermédiaire de constantes.

 switch (month) { case Calendar.DECEMBER : case Calendar.JANUARY : case Calendar.FEBRUARY : season = Season.WINTER ; break ; ... }

Avec JavaSE 5, le switch a été étendu aux types énumérés.

 enum Season { SPRING, SUMMER, FALL, WINTER ; }

 switch (season) { case WINTER : headgear = "woolly hat" ; break ; ... }

La version 7 apporte maintenant le support du type String.

 switch (headgear) { case "none" : //... break ; }

Valeurs littérales formatées

Cette nouveauté paraît anecdotique, mais peut faciliter la lecture de code qui manipule des grandes valeurs littérales numériques.

Par exemple, que vaut 2365876245 ? Deux cent millions, deux milliards, vingt milliards ? La même valeur est plus lisible si elle est écrite 2_365_876_245.

Ainsi,

 long val = 2365876245L ;

peut maintenant s'écrire

 long val = 2_365_876_245L ;

Autre nouveauté, les valeurs littérales peuvent être écrites en binaire. Jusqu'à maintenant, le décimal, l'octal et l'hexadécimal étaient supportés. Pour écrire une valeur en binaire, il faut la préfixer par 0b.

 int binaryValue = 0b011100101 ;

Pour rappel, le préfixe pour l'hexadécimal est 0x et celui pour l'octal est 0. Ainsi, la valeur 229 peut s'écrire sous les quatre formes suivantes :

 int decimalValue = 229 ; int binaryValue = 0B011100101 ; int hexaValue = 0xe5 ; int octalValue = 0345 ;

Multi-catch

Jusqu'à maintenant, dans la structure try-catch, chaque catch ne pouvait traiter qu'un seul type d'exception. Donc c'est un traitement spécifique pour chaque type d'exception attrapée.

 try { Class.forName("org.sewatech.examples.java7.MyClass").newInstance() ; //... } catch (ClassNotFoundException e) { System.err.printf("Problème de création de mon objet (%s)\n", e) ; } catch (InstantiationException e) { System.err.printf("Problème de création de mon objet (%s)\n", e) ; } catch (IllegalAccessException e) { System.err.printf("Problème de création de mon objet (%s)\n", e) ; }

On peut certes jouer avec l'héritage entre classes d'exception, mais on arrive rapidement à quelque chose comme catch(Exception ex). Sans grand intérêt.

 try { Class.forName("org.sewatech.examples.java7.MyClass").newInstance() ; //... } catch (Exception e) { System.err.printf("Problème de création de mon objet (%s)\n", e) ; }

Pour éviter ce tout-ou-rien, Java SE 7 permet maintenant de traiter plusieurs types d'exceptions, séparés par un 'pipe', pour chaque catch.

 try { Class.forName("org.sewatech.examples.java7.MyClass").newInstance() ; //... } catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) { System.err.printf("Problème de création de mon objet (%s)\n", e) ; }

Au passage, le rethrow est mieux géré, avec une meilleure inférence.

Très pratique, cette nouveauté ne devrait pas être tant utilisée que cela ; la faute aux frameworks comme hibernale, Ajp, Spring, CDI,... qui nous aident à mieux gérer les exceptions et, surtout, à en séparer le traitement du code métier.

Try-with-resources

Dans plusieurs APIs de Java, il est nécessaire de clore les ressources utilisées. C'est le cas pour JDBC ou IO et plus généralement pour celle utilisant des ressources externes. Pour éviter la fuite de ressources, il est nécessaire de mettre l'appel de la méthode de clôture dans un bloc finally. Si on ajoute à cela la gestion des exceptions, généralement validées (checked), on obtient un code très peu lisible, avec beaucoup de code qui n'a rien à voir avec l'objectif fonctionnel.

Dans l'exemple ci-dessous, on ouvre un fichier texte, qu'on lit ligne par ligne.

 BufferedReader br ; try { br = new BufferedReader(new FileReader("readme.txt")) ; try { while ((line = reader.readLine()) != null) { System.out.println(br.readLine()) ; } } catch (IOException e) { System.err.println("Problème de lecture du fichier") ; } finally { try { br.close() ; } catch (IOException ex) { } } } catch (FileNotFoundException ex) { System.err.println("Fichier non trouvé") ; }

Dans cette portion, on commence par ouvrir un flux de lecture sur le fichier et gérer l'exception d'absence de fichier. Puis on lit le fichier ligne à ligne, ce qui peut provoquer une exception d'entrée-sortie. On clôt le flux dans le finally, ce qui peut provoquer une exception d'entrée-sortie qui ne doit pas être traitée sous peine de masquer l'exception de lecture. Ça fait beaucoup de code pour lire un fichier texte...

Le try-with-resource permet de déclarer la ressource à clore dans le try, ce qui en simplifie grandement la structure.

 try (BufferedReader br = new BufferedReader(new FileReader("readme.txt"))) { String line = null ; while ((line = reader.readLine()) != null) { System.out.println(br.readLine()) ; } } catch (IOException e) { System.err.println("Problème de lecture du fichier") ; }

Cette notation peut être utilisée pour n'importe quelle classe qui implémente la nouvelle interface java.lang.AutoCloseable.

Manipulation de fichiers

L'API des entrées / sorties a eu droit a des modification non négligeables. Tout d'abord, les fonctionnalités de classe java.io.File sont reproduites et réparties dans les classes Path, Files, FileStore et FileSystem du package java.nio.file. Ensuite, le support des spécificités des systèmes de fichiers Posix est apporté, en particulier les permissions et les liens symboliques. Enfin, un système de notification a été ajouté.

Ces nouveautés apportent une meilleure organisation des responsabilités et permettent de simplifier certaines portions de code. Ainsi, l'exemple de lecture d'un fichier devient :

 try (BufferedReader reader = Files.newBufferedReader(Paths.get("readme.txt"), UTF8)) { String line = null ; while ((line = reader.readLine()) != null) { System.out.println(line) ; } }

NIO2 permet de simplifier encore ce code pour le cas des petits fichiers en nous évitant de manipuler le reader.

 List lines = Files.readAllLines(Paths.get("readme.txt"), UTF8) ; for (String line : lines) { System.out.println(line) ; }

Le site JTips fournit des détails sur les nouveautés de NIO2.

Conclusion

Cette version 7 était attendu de longue date, et sa sortie est une excellente nouvelle pour l'écosystème Java. Les migrations vont se faire très progressivement dans les entreprises, probablement longtemps après la fin de vie du JDK 6, en juillet 2012.

Maintenant, nous attendons impatiemment la version 8 dont le contenu devrait changer le langage beaucoup plus en profondeur, avec la modularité, les closures et d'autres nouveautés.

La priorité est aujourd'hui d'utiliser Java 7, et pour cela, Sewatech a mis ses formations à jour, en particulier Initiation au langage java et Approfondissement java.

Administration JBoss 6

Alexis Hassler — 2011-03-31T22:00:00Z

Cette version JBoss AS 6 apporte avant tout le support du standard JavaEE 6, en particulier du Web Profile.

D'un point de vue administration, plusieurs changements profonds par rapport aux versions précédentes nous obligent à ajuster nos pratiques. Ces changements concernent le logging, JMS, le déploiement à la demande et le management JMX.

Programme du cours

Introduction à JavaEE et JBoss
Présentation de Java et de JavaEE
Typologie des applications JavaEE
Présentation de JBoss
Organisation et techniques d'organisation
Principale tâches d'administration

Bases de l'administration de JBoss AS
Installation, démarrage et arrêt
Principe des configurations, standards et personnalisées
Déploiement d'applications (ear, war, jar,...)
Console d'administration et déploiement à la demande
Gestion centralisée avec JOPR

Gestion des ressources et des accès
Accès Web : HTTP, HTTPS, AJP
Gestion des librairies et isolation des applications
Composants et JNDI
JNDI sur JNP / RMI ou HTTP
Accès aux base de données : datasource
Destinations JMS
Ports utilisés et gestion des conflits

Suivi et surveillance du serveur
Les traces d'accès Web
Les traces du serveur avec LogManager
Les traces applicatives avec Log4J ou java.util.logging
Les métriques dans la console d'administration
La console JMX
L'interrogation en ligne de commande avec twiddle
Les accès JMX avec jConsole

Sécurité du serveur et des applications
Les objectifs de sécurisation du serveur
Le modèle de sécurité JBoss AS
La gestion des autorisations et des authentifications en JavaEE (JAAS)
La sécurisation des accès et des consoles
La sécurisation des échanges avec SSL

Amélioration des performances
Le tuning de la machine virtuelle
La dimensionnement des pools (EJB, DataSource, threads)
Le retrait de composants inutiles
Le clustering pour la tolérance de panne (failover) et la répartition de charge (load balancing)

Administration JMS
Un rappel des principes de JMS
La configuration des destination dans HornetQ
La répartition de la charge avec HornetQ
La tolérance de panne

A chaque étape, les stagiaires mettent en œuvre les techniques présentées, en déployant des applications JavaEE et en intervenant dans les différents réglages de JBoss AS.

Les exercices pratiques sont réalisés avec le JDK 6 d'Oracle et JBoss AS 6 sous Windows, Linux ou Unix (Solaris,...).

Travaux pratiques Java

Alexis Hassler — 2011-02-22T01:41:41Z

Les travaux pratiques de toutes nos formations Java peuvent être organisés dans des environnements variés. Pour chaque session de formation intra-entreprise, nous laissons le choix à notre client entre plusieurs systèmes d'exploitation, plusieurs outils de développement et, le cas échéant, plusieurs serveurs d'applications ainsi que plusieurs bases de données.

Pour les logiciels propriétaires, le client doit être en possession d'une licence pour chaque poste de stagiaire, excepté pour IntelliJ IDEA, pour lequel Jetbrains nous fait bénéficier d'une licence classroom.

Système d'exploitation

Linux Ubuntu (notre préféré)
Linux Fedora, RHEL,...
Apple MacOS X
Microsoft Windows

Outil de développement

Can't code withoutSmart Java IDE. Web development ready.
Neat HTML and CSS refactorings and more

Nous pouvons aussi utiliser une suite basée sur Eclipse, comme MyEclipse, Spring Tool Suite ou JBoss Developer Studio.

Serveur d'applications

JBoss
Glassfish

Base de données

MySql
H2, HsqlDB ou Apache Derby
...

CDI, le coeur de JavaEE 6

Alexis Hassler — 2011-01-30T21:26:33Z

CDI, Context and Dependency Injection, est une nouveauté majeure de Java EE 6. Java EE 5 ne permet l'injection que d'EJB et de ressources gérées par le serveur d'application. En comparaison de Spring Framework, cette version de la spécification manque cruellement de souplesse. CDI permet d'injecter des composants plus variés et propose des techniques d'événements, d'interception ou de décoration. CDI devient donc un élément essentiel de JavaEE.

Cette formation permet de prendre en main les techniques proposées par CDI : injection, interception, événements. Elle aborde aussi les techniques d'extension à CDI de Weld et Seam 3.

Programme de la formation

Principes d'architecture
La plate-forme Java EE 6
Les frameworks d'injection
Les techniques d'injection

Premiers pas avec CDI
Implémenter le composant
Tester le composant
Configurer CDI : fichier beans.xml

Manipuler des beans
La définition d'un bean CDI
L'injection de bean
Le cycle de vie et les portées
Les fabriques de beans

Enrichissement des beans
L'interception de méthodes
La décoration
Le mécanisme d'événements

Intégration dans Java EE 6
L'intégration avec JSF
L'intégration avec JPA
L'intégration avec EJB

Extensions à CDI
Weld : implémentation de référence et extensions
Le framework Seam 3
La gestion des exceptions
la persistance et les transactions
Les techniques d'extension : Seam Solder

Les nombreux exercices pratiques ont pour objectif de prouver la simplicité de CDI et les possibilités offertes. Ils sont réalisés avec l'IDE Eclipse, Netbeans ou IntelliJ IDEA et le serveur d'applications Glassfish 3 ou JBoss AS 6.
plus de détails sur les environnements de TP...

Développement d'applications JavaEE 6

Alexis Hassler — 2011-01-24T08:59:15Z

Cette formation vous apprendra à élaborer une architecture avec les techniques de JavaEE 6.

Grâce à ses ateliers pratiques, vous saurez comment développer simplement une application basée sur JSF, EJB, JPA, Bean Validation et CDI, ainsi que JAX-WS et RS.

Programme de la formation

Introduction
Un historique de Java et JavaEE
La compétition entre standards et frameworks
La nouvelle philosophie de JavaEE : retour à la simplicité
Les architectures des applications JavaEE
Les profils : Web et complet
Les outils : IDE et serveurs applications

Composants et dépendances
Les composants métier EJB 3.1
Les EJB avec ou sans état
Les interfaces locales, distantes ou pas d'interface ?
L'EJB Singleton
Le Timer Service
Les méthodes asynchrones
L'injection de composants : Managed Beans et DI 1.0
Le modèle de composants CDI
Les portées (scopes) prédéfinis
Les producteurs de beans
La sécurité des composants

Gestion de la persistance
Le mapping objet / relationnel avec JPA 2
Le PersistenceContext
Les annotations de mapping
Les associations
L'API Criteria
La gestion des transactions avec JPA et EJB

Gestion de l'affichage
Le principe des JSP et servlets 3.0
La prise en compte des requêtes asynchrones
Le développement de page JSF 2
Un framework orienté composants
Les templates Facelets
Les Managed Beans
Le langage d'expression
La gestion d'évènements
Les convertisseurs et validateurs
La définition de la navigation
Les composants AJAX : PrimeFaces, RichFaces,...

Services transverses
Le framework de validation
Bean Validation
Web Services avec JAX-WS
Services RESTful avec JAX-RS

Synthèse
Retour sur l'architecture JavaEE 6
Avantages par rapport aux versions précédentes
Comparaison avec Spring Framework

Les nombreux exercices pratiques ont pour objectif de prouver la simplicité de mise en œuvre des techniques de JavaEE 6. Ils sont réalisés avec l'IDE Eclipse, Netbeans ou IntelliJ IDEA et le serveur d'applications Glassfish 3 ou JBoss AS 7.
plus de détails sur les environnements de TP...

Enrichir les logs avec LogWEx

Alexis Hassler — 2010-09-02T20:46:30Z

Plaçons nous dans le cadre d'une application développée correctement, avec des bonnes traces envoyées dans un utilitaire correct de type Log4J, éventuellement via une façade comme commons-logging ou, beaucoup mieux, SLF4J. Grâce à la configuration de Log4J, il est possible de choisir les informations qui apparaissent dans les fichiers de logs en plus du message à proprement parler : heure, niveau du log (erreur, alerte, info, debug, trace), le logger d'origine. Lorsqu'on est en développement, on peut aussi ajouter des informations plus précises sur l'origine comme la méthode et la ligne de code qui a envoyé le message.

Il nous manque souvent une information important : quel utilisateur a été à l'origine du log ? Qu'a fait ce même utilisateur avant d'en arriver là ? Voyons comment on peut avoir ces informations dans les logs...

Dans les logs des applications Web, on ajoute très souvent le nom du thread. Ceci permet de reconstituer une séquence de traces qui correspond au traitement d'une requête HTTP. En effet, dans les serveurs d'applications Web classiques, comme Tomcat, Jetty, JBoss, Weblogic,…, un thread est affecté au traitement de chaque requête, jusqu'à la production de la réponse. Par contre, plusieurs requêtes consécutives d'un même utilisateur peuvent très bien être traitées par des threads différents. L'affichage du nom du thread dans les logs est donc insuffisant pour reconstituer un historique plus important pour un utilisateur.

Il existe plusieurs techniques pour obtenir un résultat satisfaisant. La façon la plus riche est d'utiliser des outils dédié aux audits. Pour plus d'informations sur le sujet, je vous renverrais vers l'article de Cyrille Leclerc et David Galichet et aux discussions associées. Dans mon cas, je vais m'intéresser aux applications pour lesquelles un tel besoin n'a pas été pris en compte au développement. En gros, on n'a que les logs. Dans ce cas, la technique qui ne nécessite aucun développement passe par un croisement entre les logs applicatifs et les logs d'accès (cf. AccessLogValve, pour Tomcat). Ce dernier nous donne des informations comme l'Id de session, l'utilisateur authentifié, s'il l'a été par une technique standard et le nom de thread. Tout cela est réalisable puisque le nom du thread est présent dans les deux fichiers, mais fastidieux.

Donc il va falloir développer. Au minimum, il faut faire un filtre qui va intercepter les requêtes. Pour chaque requête, on peut envoyer une trace de début et une trace de fin, avec les mêmes informations que pour les logs d'accès, à la différence que dans le cas du filtre, les traces sortiront avec les logs applicatifs. En centralisant ces traces, l'exploitation est un peu plus simple.

L'idéal serait d'avoir toutes les informations directement dans chaque trace applicative. Dans ce cas, des outils rudimentaires comme grec ou un tableur suffiront pour exploiter les informations. Pour arriver à ce résultat, on va utiliser le MDC (Mapped Diagnostic Context) de Log4J pour que notre filtre y stocke les informations nécessaires (identifiant de session, nom d'utilisateur,...).

 MDC.put("session.id", session.getId()) ;

Une fois les informations présentes dans le MDC, il est facile de paramétrer la layout de Log4 pour qu'elles sortent dans les fichiers de logs : %Xsession.id. L'avantage de cette technique, c'est qu'on n'est plus obligé de ce contenter d'information standards, on peut très facilement ajouter des informations présentes en attributs de session et les ajouter au MDC.

Ayant eu à développer ce type de filtre pour plusieurs clients, nous avons décider de développer un tel filtre sous licence Open Source, sous le nom de LogWEx (Logging Extra for Web applications). L'objectif du projet est de vous fournir un filtre générique qui vous fournisse les informations nécessaire uniquement par configuration, sans développement.

La première version ne fournit que l'identifiant de session, le nom de l'utilisateur et les propriétés de la requête (hosto, port, pat,…). Les prochaines versions devraient s'enrichir rapidement pour atteindre l'objectif. Pour l'instant, LogWEx n'est utilisable qu'avec Log4J car c'est l'outil le plus utilisé par nos clients, mais nous évaluerons rapidement l'opportunité de supporter aussi LogBack qui est les meilleur outil de log du moment.

J'invite donc tous ceux qui veulent enrichir leurs logs à essayer LogWEx et à nous faire leurs retours sur le bug tracker du projet sur GitHub.

Pour en savoir plus : projet LogWEx

Administration Tomcat en cluster

Alexis Hassler — 2010-04-30T21:57:49Z

Ce cours avancé vous permettra de mettre en place des architectures en cluster avec Tomcat.

Vous verrez le déploiement en répartition de charge avec un serveur frontal Apache et vous verrez les modes de réplication de session.

Plan de la formation

Architecture de déploiement et services de Clustering
— Installation de Tomcat autonome
— Installation avec un frontal Web
— Présentation des solutions : IIS ou Apache, HTTP ou AJP, mod_proxy ou mod_jk
— Définition d'un Cluster
— Services de répartition de charge et de
— Services de haute disponibilité

Installation avec Apache en reverse proxy
— Apache avec mod_proxy
— Impact de cette architecture sur les logs
— Gestion des en-têtes HTTP : RemoteIpValve, préservation du host
— Gestion des contextes Web
— Gestion des hôtes virtuels
— Partage et déport de ressources statiques
— Chiffrement SSL entre Apache et Tomcat
— Support du protocole AJP
— Installation alternative avec le mod_jk

Gestion du Load Balancing
— Répartition de charge entre plusieurs Tomcat avec mod_proxy_balancer
— Suivi de la répartition avec balancer_manager
— Algorithmes et critères de répartition
— Affinité de session et gestion des routes, impact sur les sessions
— Limites de cette architecture : la sensibilité aux pannes

Service de haute disponibilité
— Sessions et tolérance de panne
— Composant Cluster dans Tomcat
— Synchronisation des sessions par réplication
— Gestion dynamique des membres du cluster par multicast
— Gestion statique des membres
— Installation de grappes de Tomcat
— Déploiement d'applications par farming

Compléments
— Haute disponibilité croisée entre Apache et Tomcat
— Synchronisation des sessions par Terracota

Pour chaque partie, mise en œuvre pratique avec déploiement d'applications.

Ils sont réalisés avec le JDK 5 ou 6 de Sun et Tomcat 6.0, sous Windows ou Linux. Ils peuvent être réalisés sur des machines virtuelles ou physiques.

Framework MVC - Struts 2

Alexis Hassler — 2010-02-21T23:22:10Z

Le MVC (Modèle-Vue-Contrôleur) est le principe d'architecture le plus répandu dans le développement d'applications Web en java. Le framework Struts 2, issu de la fusion entre le très populaire Struts 1 et le réputé WebWork, est une des références en la matière.

Ce cours vous permettra de comprendre le pattern MVC tel qu'il est implémenté dans Struts 2 et vous apprendra à développer des applications Web/JSP avec le framework Struts 2.

Programme de la formation

Présentation du framework
Les origines de Struts 2
Un framework pour le web
Principe du framework

Premiers pas avec Struts 2
Un formulaire simple avec sa classe d'action
La configuration
Le déploiement

Développement des actions
Les classes d'actions
L'organisation des actions
Les méthodes d'invocation
L'utilisation des caractères joker

Validation des données
Principe du framework de validation
Les validateurs prédéfinis
Ecrire un validateurs personnalisé
La validation javascript, côté client
La validation par annotations

Développements de JSP avec Struts
Le contexte de nommage des objets
Le langage d'expression OGNL
La syntaxe OGNL
La librairie de balises Struts : contrôle, données et formulaire

Personnalisation du rendu des pages
Les thèmes et templates
Le langage Freemarker
La composition des pages avec Tiles et Sitemesh

Internationalisation
Les techniques d'internationalisation
Le chargement des fichiers de traduction
La gestion des cultures (Locale)

Programmation Ajax
Le thème Ajax
Les tags Ajax

Des exercices pratiques permettent d'illustrer les différents sujets abordés dans le cours. Ils sont réalisés avec Eclipse, Netbeans ou IntelliJ IDEA, avec le serveur d'applications Apache Tomcat, JBoss ou Glassfish.
plus de détails sur les environnements de TP...

_

Alexis Hassler — 2009-04-03T09:41:01Z

- actualités

Spring : les bases

Alexis Hassler — 2009-02-22T23:04:24Z

Le framework Spring offre de nombreuses possibilités au développeur. Acquérir des connaissances sur l'ensemble des fonctionnalités peut s'avérer long et coûteux. C'est pour cela que cette formation se concentre sur l'essentiel des fonctionnalités de Spring, pour plus d'efficacité.

A l'issue de cette formation, vous serez en mesure de développer des applications JavaEE basées sur Spring.

Programme du cours

Présentation des principes fondamentaux de Spring Framework
Les techniques de développement Java EE
Les frameworks Java spécialisés : MVC, mapping O/R,...
Les conteneurs légers
L'IoC : inversion de contrôle
Les fonctionnalités du framework Spring

Premiers pas avec Spring
L'implémentation dans une classe
La configuration du conteneur
L'accès au bean

Manipulation les beans Spring
La définition des beans et les méthodes de fabrique
L'injection des dépendances
La portée des beans
La configuration XML ou par annotations
L'externalisation par properties

Accès aux données avec Spring JDBC et Hibernate
La couche d'abstraction pour JDBC
L'intégration avec Hibernate
La gestion déclarative des transactions

Application web avec Spring / JSF
Rappels sur la programmation avec JSF
L'intégration des beans JSF

Test de composants Spring
L'intégration avec JUnit
L'ApplicationContext dans les tests (mode dirty)
Les transactions dans les tests

Sécurité avec Spring Security
Présentation du module Spring Security
La gestion des autorisations
La gestion de l'authentification

Les nombreux exercices pratiques sont réalisés avec Eclipse, Netbeans ou IntelliJ IDEA.
plus de détails sur les environnements de TP...

WebService : développement avec JAX-WS

Alexis Hassler — 2009-02-20T11:26:39Z

La principale avancée de JAX-WS est la possibilité d'utiliser les annotations pour la déclaration et la configuration des services, ce qui permet à Java de rattraper un retard de plusieurs années par rapport à son concurrent .NET.

A l'issue de cette formation, vous connaîtrez les techniques de développement de services Web avec Java et vous serez capable de mettre en œuvre JAX-WS au sein d'applications JavaEE et avec le framework Spring

Programme de la formation

Présentation des WebServices
Un historique des techniques d'interopérabilité
Le socle technique des WebServices : http, XML
Un rappel sur XML
Les protocoles des Services Web
La terminologie associée
Les services dans une architecture
Quelques cas d'utilisation et contre-exemples

Présentation des protocoles
Les messages XML avec SOAP (Simple Object Access Protocol)
La description des service avec WSDL (Web Service Description Langage)
Les annuaires de services UDDI (Universal Description, Discovery and Integration)
La pile des protocoles WS-*

Solutions et standards Java
Le traitement des données XML avec JAX-P, JAX-B, SAAJ
L'appel de procédures distantes avec JAX-RPC et JAX-WS
L'intégration dans les serveurs d'applications
Le kit WSDP (Java Web Service Developer)
Les implémentations de référence : Metro, Jersey,...
Les outils Apache : Axis et CXF
Les possibilités offertes par Spring Framework
Les démarches : description-first ou code-first

Mise en œuvre de JAX-WS
Un rappel sur la pile des techniques JAX-*
Le développement d'un service par annotation
La personnalisation du service
Le binding des arguments avec JAX-B
Les utilitaires wsconsume et wsgen

Mise en œuvre avec Spring Framework
Le choix entre Apache CXF et Spring-WS
CXF : principe et mise en œuvre
L'intégration de CXF dans Spring
Les principes de Spring-WS
Le développement de services avec Spring-WS
Le développement JAX-WS avec Spring

Les nombreux exercices pratiques sont réalisés avec Eclipse, Netbeans ou IntelliJ IDEA.
plus de détails sur les environnements de TP...

Maven : utilisation et administration

Alexis Hassler — 2009-02-16T12:34:50Z

Ce cours est destiné à tous ceux qui se posent les questions suivantes : "Quels sont les bénéfices réels de l'intégration continue ?", "Quels sont les apports de Maven par rapport à des outils plus classiques comme ANT ?", ou de manière plus pratique "Comment mettre en oeuvre Maven comme outil de construction ?", ou ''Quelle intégration entre Maven et des outils comme Subversion, ou encore le serveur d'intégration continue type Continuum ? » .

Programme du cours

Introduction
— Maven : présentation et historique
— Maven dans le cycle de vie des projets
— Priorité de la convention sur la configuration

POM : Project Object Model
— Gestion des objets par Maven
— Fiche projet : pom.xml
— « Super POM » et mécanismes d'héritage
— Structure des projets
— Types de projets Maven : Simple, Web, Entreprise, ...
— Propriétés et de filtre des ressources

Référentiel Maven et coordinations
— Localisation d'une librairie
— Référentiel (repository) et architecture organisationnelle
— Repository local et distants
— Gestion du cache et de la sécurité : Archiva
— Pré-requis et installation de Maven
— Présentation et installation des techniques de configuration

Modèle de gestion des dépendances
— Gestion des dépendances et transitivité
— Optimisation des dépendances
— Cycle de construction d'un projet
— Phases et rattachement des goals Maven aux différents cycles
— Plateforme d'exécution de plugins

Les profils
— Définition et intérêt des profils
— Configuration et mise en œuvre
— Bonnes pratiques

Développement de plugins
— Création d'un plugin en Java
— Création d'un type de projet
— Debug de l'exécution d'un plugin dans un IDE
— Groovy comme langage alternatif

Archetype et Assemblies
— Définition et spectre des archetypes existants
— Génération de livrable à la demande

Gestion de configuration
— Communication avec un gestionnaire de sources
— Fabrication d'un livrable et détails des pré-requis

Organisation des tests
— Organisation Maven pour les tests d'intégration et fonctionnels
— Debug des tests dans Eclipse
— Tests d'intégration s'exécutant au sein d'un navigateur Web

Génération de rapports
— Génération du site Maven de projet
— Génération de rapports : Javadoc, couverture de code, détection de bugs, normes dev.
— Techniques de déploiement du site

Maven dans les équipes de développement
— Modes d'utilisation de Maven avec Eclipse
— Plugin m2eclipse

Intégration continue
— Problématiques et enjeux
— Outillages et mise en pratique avec Hudson

Limites, avantages et futures évolutions
— Comparaison entre Maven et Gradle
— Gestion d'un build incrémental

Subversion : utilisation et administration

Alexis Hassler — 2009-02-16T10:54:18Z

Successeur de CVS et Open Source, Subversion est aujourd'hui le logiciel de gestion de configuration le plus utilisé.

Cette formation vous permettra de comprendre les enjeux d'un tel outil. Elle vous apprendra à utiliser subversion et à gérer ses serveurs.

Plan

Introduction
— Problématique du travail en équipe
— Organisation des tâches par domaine fonctionnel
— Accès concurrents aux ressources partagées
— Périmètres partageables
— Historique de Subversion et relation à CVS
— Tour d'horizon rapide des SCM (Source Code Management)

Architecture de Subversion
— Serveurs Subversion
— Protocoles d'accès aux serveurs
— Concept de dépôt (repository)
— Structuration d'un dépôt
— Clients de subversion et critères de choix

Concepts élémentaires de Subversion
— Définition d'un dépôt
— Définition d'un changes et et d'une révision
— Gestion des répertoires et des fichiers
— URL de chaque ressource
— Gestion des méta-données
— Organisation en branches et balises (tags)

Utilisation quotidienne
— Importation de contenu existant
— Récupération du contenu d'un repository
— Propagation d'une modification
— Synchronisations et résolution des conflits (merges)
— Retrouver l'auteur d'une modification

Administration des dépôts
— Création d'un dépôt
— Organisation d'un dépôt
— Utiliser les outils d'administration et de monitoring
— Export et import d'un dépôt
— Contrôle du contenu d'un dépôt
— Réparation d'un dépôt
— Sauvegardes à froid et à chaud, automatisées
— Scripting des événements (hook scripts)
— Envoi de mails lors des validation (commit)

Administration des serveurs
— SVNServe et d'Apache mod_dav_svn : présentation et critères de choix
— Configuration d'un Apache mod_dav_svn
— Configuration d'un SVNServe
— Sécurisation des échanges avec SSL

Administration JOnAS

Alexis Hassler — 2009-02-16T10:07:56Z

JOnAS a été un des tous premiers serveurs d'applications Java Open Source. Il a aussi été le premier à obtenir la certification J2EE, dans cette catégorie. Il a depuis longtemps fait preuve de robustesse et d'un bon niveau de performance.

Dans cette formation, vous apprendrez à installer JOnAS, à y déployer des applications JavaEE ainsi qu'à accomplir les principales tâches d'administration.

Plan du cours

Présentation et premiers pas
— Présentation du consortium ObjectWeb
— Architecture de JOnAS
— Pré-requis, installation et démarrage
— Intégration avec Tomcat
— Organisation des répertoires

Configuration des services JOnAS
— Gestion des principaux services (JavaMail, JMS, JTA...)
— Le registre JNDI
— Installation et utilisation des DataSources et des pools de connexions

Console d'administration
— Mise en place de la console d'administration
— Utilisation de la console pour le déploiement d'une application, la visualisation des logs...

Déploiement d'applications JavaEE
— Applications Web : archives war
— Applications d'entreprise : archives ear

Gestion des droits utilisateurs
— Authentifications et autorisations
— Mise en œuvre des realm
— Modes de stockage des droits (fichier plat, base de données, LDAP)
— Gestion des droits avec JAAS : rôles et groupes de permissions

Administration avancée
— Technique de scripting pour l'automatisation des tâches récurrentes
— Connexions inter-applicatives avec JCA

Interfaçage avec Apache HttpServer
— Installation du connecteur mod_jk
— Les performances / disponibilités
— Mise en place d'un cluster avec deux nœuds pour le serveur d'applications
— Monitoring et tuning
— Analyse des fichiers de journalisation (logs)

Spécificités de Jonas
— JORAM : Java (TM) Open Reliable Asynchronous Messaging
— Carol : RMI en souplesse
— Jonathan : an Open Distributed Objects Platform
— Jeremie
— JOTM : gestion des transactions
— C-JDBC : Clustered JDBC

Chaque partie fait l'objet d'une mise en œuvre pratique, réalisée avec le JDK 5.0 ou 6 de Sun et JOnAS 4.x sous Windows, Linux ou Unix (Solaris,...).