Il y a 14 ans -

Temps de lecture 7 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

SOA

Le coin de la technique


Agilité

Nouveaux plugins pour Hudson

La famille des plugins Hudson s’agrandit avec un plugin Perforce et un plugin VMWare. Perforce vient donc s’ajouter à la liste de SCM supportés (CVS, Subversion, ClearCase, Mercurial, Perforce et Visual Source Safe) ce qui est une bonne nouvelle pour les utilisateurs de cette solution. Le plugin VMWare permet quant à lui de démarrer/arrêter un environnement VMWare lors d’un build et donc de tester différents environnements sur un même système. Hudson, toujours aussi dynamique!

Les patterns d’adoption de l’agilité

Dans cet article, Claude Aubry (consultant et enseignant sur les méthodes agiles), nous présente différentes façon d’aborder les méthodes agiles dans une organisation souhaitant les mettre en place. Il nous montre ainsi les façons les plus fréquentes dont se déroulent les transitions à l’agilité. Néanmoins, il souligne le fait que ces patterns dépendent du contexte et ne doivent pas être appliqués « à la lettre ».

SOA

Les stacks WS Open Source WS Stacks pour Java – Buts et philosophie

Dans Open Source WS Stacks for Java – Design Goals and Philosophy, InfoQ interview des responsables des principaux frameworks de Web Services (Metro/JAXWS-RI, CXF, Axis2, Spring WS et JBossWS) et nous fait découvrir leurs objectifs.

Les points essentiels :

  • JAXWS est le standard à utiliser dès aujourd’hui pour écrire des Web Services (Java 5+). Seul le balbutiant Spring WS (Août 2007) n’implémente pas JAXWS.
  • Metro / JAXWS-RI est le seul projet dédié uniquement à JAXWS.
    • CXF est un bus de messages
    • Axis2 est une sorte de serveur d’application avec ses modules .aar déployables à chaud et une architecture destinée à des implémentations en C et Java 1.4+.
    • Spring WS propose un modèle exclusivement WSDL2Java qui se veut plus simple que JAXWS.
    • JBoss WS est un projet très modulaire qui peut, entre autre, embarquer CXF ou JAXWS-RI.
  • Interopérabilité : sujet crucial pour les Web Services, en particulier vers les plateformes Microsoft .Net/WCF. Sun se démarque une fois de plus des autres acteurs Java avec un projet dédié à l’intéropérabilité .Net (WSIT), des équipes dédiées aux tests et des échanges réguliers avec le managemet de Microsoft.
  • REST : REST est un modèle d’architecture à part entière et ne se limite pas simplement à un style d’URL. Les projets SOAP avancent avec précaution sur ce sujet.
  • Maturité : chaque projet se prétend être très mature. On remarquera quand même
    • JAXWS-RI est embarqué par Weblogic 10 et va donc être largement utilisé par les clients BEA. Dans le même temps, la version d’Axis 2 embarquée par Websphere 6.1 Web Services Feature Pack est sensiblement customizée ; il ne s’agit plus du même produit.
    • Axis2 et CXF ne sont pas des simples évolutions de leurs aînés (respectivement Axis 1 et XFire) mais bien des réécritures majeures.

Il est difficile de prendre position sur de simples interviews mais nos expériences SOAP avec les différents frameworks (JAXWS-RI, CXF, Axis2 et Axis2 by Websphere 6.1) nous ont montré la très solide position de JAXWS-RI … et nous espérons vous en reparler bientôt avec des cas d’utilisation de la vraie vie de l’informatique de gestion!

Le coin de la technique

Quelle police pour coder?

Dans son blog Coding Horror, l’auteur se demande quelle est la meilleure police de caractère pour développer. Pour montrer les différences, il expose le même source avec différences polices. Ensuite effectivement c’est une affaire de goûts et d’habitude. Son choix: la police ‘Consola’ livrée par défaut avec Vista. Il existe une version X11/Linux en cours de développement, Incolata.

Encore un débat sur les frameworks de log

The Server Side relance le débat sur le choix du framework de log avec Logging API choices. L’occasion pour nous de défendre le choix pragmatique de Log4J pour de l’informatique de gestion :

  • Log4j avec son fichier log4j.properties est le standard de facto auquel on reprochera quand même :
    • de ne pas offrir de vrais moyens d’administration par JMX
    • de ne pas supporter les varargs introduits par Java5
    • d’avoir introduit de la confusion avec le fichier log4j.xml qui, s’il est séduisant pour les équipes de développement, est inadapté aux réalités des équipes d’exploitation qui travaillent par chercher-remplacer
  • Jakarta Commons Logging n’est pas adapté aux applications standalone dixit son concepteur Rod Waldhoff dans Commons Logging was my fault : If you’re building a stand-alone application, don’t use commons-logging.
  • java.util.logging est très pénible à utiliser dans un serveur d’application comme le résume très bien la documentation Tomcat : logging. Les utilisateurs de Websphere auront le soulagement de découvrir que la version 6.1 permet de configurer java.util.logging depuis la console d’administration plutôt que de modifier le fichier $JAVA_HOME/jre/lib/logging.properties (InfoCenter : Configuring Java logging using the administrative console)
  • SLF4J est sûrement très bien adapté aux applications embarquables (middlewares, frameworks web etc. ) mais présente peu d’arguments face à Log4j pour des applications standalone. Il se justifie donc très rarement en informatique de gestion.

Performances et gestion des ressources JMS

Dans Using JMS Connection Pooling with Websphere, IBM nous explique comment le pooling des ressources JCA par un serveur J2EE s’applique au cas des ressources JMS (Connection, Session, MessageProducer et MessageConsumer).

Cet article rappellera aux pourfendeurs des serveurs J2EE que Spring n’est pas une alternative à ces serveurs mais seulement aux conteneurs EJBs. Quelques exemples de services J2EE pour lesquels SpringFramework repose sur une serveur d’application ou une implémentation standalone :

  • JCA – pooling des ressources: Active MQ – JmsTemplate Gotchas « If not using in an EJB then use Jencks to create the ConnectionFactory » (Jencks est un conteneur JCA léger). Nous noterons la confusion entre EJB et ConnexionFactory gérée par un conteneur JCA dans la documentation d’ActiveMQ :-) .
  • JTA – transactions distribuées : Spring Documentation – Transactions Typically you need an application server’s JTA capability only if you need to enlist multiple transactional resources … Standalone transaction managers such as Atomikos Transactions and JOTM are other options

Utiliser le DefaultMessageListenerContainer de SpringFramework avec la ConnexionFactory JMS et le pool de threads WorkManager de Websphere permet de concilier le meilleur des deux mondes (simplicité, supervision et performances) tout en restant supporté par IBM (cf. developerWorks : Using Spring and Hibernate with WebSphere Application Server)

Clarification des mesures : JSR 275 – Measures and units

Les mesures et leur unité ont jusqu’à présent été très floues en Java. java.sql avait timidement amorcé la clarification entre les dates, les heures et les dates-heures (Date, Time et Timestamp). java.util.concurrent a suivi en précisant les durées avec TimeUnit (millis, secondes, minutes etc.). Jean-Marie Dautelle nous explique dans Introduction to JSR-275: Measures and Units comment l’apparition des génériques avec Java5 à permis la rédaction d’une spécification pour clarifier les mesures et leur unité.

Si cette spécification bénéficierait surtout au monde scientifique, elle pourrait aussi servir à l’informatique de gestion pour décrire sans ambiguïté les mesures (durées, longueurs, poids etc.) :

Measure<Integer, Duration> manifacturingDuration = Measure.valueOf(8, MINUTES);
Measurable<Length> employeeHeight = Measure.valueOf(180, CENTIMETER);
Measurable<Mass> parcelWeight = Measure.valueOf(75, KILOGRAM);

Alors, pourquoi le conditionnel ? Parce que la JSR 275 a un précédent. La JSR 108 – Units Specification a été abandonnée en 2004 et les membres du JCP ne sont guère plus optimistes pour sa réincarnation en JSR 275. Les raisons invoquées sont toujours le manque d’intérêt de la communauté Java et la complexité de l’API.

Pour conclure sur une touche d’optimisme, cet article nous fait sourire avec ce bug tellement énorme qu’il en est drôle : la Nasa a perdu la sonde Mars Orbiter (125 millions de dollars) à cause d’un quiproquo entre équipes de développement qui parlaient de longueurs en inches et en centimètres!

Commentaire

3 réponses pour " Revue de Presse Xebia "

  1. Published by , Il y a 14 ans

    A propos des polices, Jeff Artwood a en fait écrit deux articles.
    Un premier qui concerne les polices bitmap (enfin, je crois) où on trouve proggy, que j’utilise tous les jours, et un second (celui que vous présentez) qui décrit des polices monospaces plus « vectorielles ».
    En tout cas, les deux articles sont à lire. En fait, tout Coding horror est à lire, tant les principes qu’il expose dans son blog sont ceux qui conduisent à des développements de qualité.

    A propos des frameworks de log, j’ai longtemps utilisé log4j (dans tomcat), et je suis passé récement à util.logging et je le trouve, malgré quelques légères différences, assez agréable à utiliser dans une application Swing.

  2. Published by , Il y a 14 ans

    Bonjour Nicolas et merci pour votre intérêt,

    Voici un florilège de limitations que je vois à java.util.logging :

    – La configuration est de portée JVM et non de portée ClassLoader. C’est ingérable dans un moteur de servlets ou un serveur d’application.

    – Le fichier de configuration n’est pas embarqué par l’application mais par la JVM ($JAVA_HOME/jre/lib/logging.properties). Modifier un fichier embarqué par la JVM est très gênant (traçabilité, contraintes d’exploitation, etc.) et la seule alternative est d’utiliser une pesante variable système (« java.util.logging.config.file »).

    – Le seul formatter de message disponible (si l’on exclue le XMLFormatter) impose un format très mal pratique
    — message sur deux lignes : adieux les « grep » pour analyser les logs
    — format de date qui ne permet pas le tri alphabétique pour ordonner – d/M/yy au lieu de yy/MM/dd : adieux la corrélation de logs provenant de plusieurs fichiers
    — performances incompatible avec un environnement de production : SimpleFormatter génère une StackStrace à chaque message pour découvrir le nom de la classe et de la méthode appelante alors que nous savons que générer une StackTrace est très consommateur pour une JVM

    – Les APIs sont incomplètes, il manque des méthodes :
    — il existe bien logger.info(message)
    — il manque logger.isInfoEnabled() que je dois contourner par le pesant logger.isLoggable(Level.INFO)
    — il manque logger.info(message, throwable) pour lequel je dois me contenter de logger.log(Level.INFO, message, throwable)

    – Enfin, les noms des niveaux de log sont inhabituels aux équipe de dev et suscitent encore plus de débats sur le niveau à choisir (« finest », « finer », « fine » etc versus « trace », « debug »)

    Moralité, sur les projets d’informatique de gestion utilisant java.util.logging que j’ai vu, les développeurs loggaient avec System.out.println(), printStackTrace() et l’utilisation de niveaux trop elevés (INFO et +) pour utiliser le fichier de configuration par défaut de la JVM.

    Cette liste de doléances est bien entendu un liste de souhaits pour la nouvelle version de java.util.logging ;-)

    En attendant, si vous avez des tuyaux pour m’aider à mieux vivre java.util.logger, je suis interessé :-)

    Cyrille

  3. Published by , Il y a 14 ans

    Bonjour Cyrille,

    petite précision : tous les loggers utilisent un stackTrace pour récupérer le nom de la classe et de la méthode où se trouve le log, pour la simple raison qu’il n’y a pas d’autre moyen de les obtenir. Log4j et ses réincarnations également.

    Malheureusement, pour des raisons purements politiques, SUN a décidé de créer son propre système de log il y a des années, à une époque où log4j était la norme universellement admise. Cela a eu pour conséquences la création de l’infâme CLog (Commons Log), qui est une surcouche du système de log sous-jacent, et d’autre part la naissance d’une série de clones (nlog4j, slf4j, logback…) de log4j dans une tentative désespérée de permettre l’intégration des composants au sein de serveurs d’applications, sans générer tous les problèmes de class loader que l’on rencontre classiquement.

    En conclusion, SUN a fait la plus belle c****erie de sa vie en développant son propre logger, par ailleurs très inférieur en fonctionalités par rapport à log4j.

    Il est hallucinant de penser que l’on subit cela depuis maintenant 5 ans, quand une solution à la java.util.concurrent aurait été tellement plus simple.

    Aujourd’hui, je pense qu’il est indispensable de ne plus utiliser JUL, mais de basculer à slf4j. Bien sûr, pour une application standalone, on peut se poser la question, mais une fois qu’on a utilisé les différents formateurs et appenders de log4j (socketAppender, SMTP Appender, etc), je ne vois aucun intérêt à utiliser les classes standards de java…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.