L’idée part d’un besoin simple : lancer un job Quartz toutes les heures ouvrées, hors week-end et jours fériés.
Pas très compliqué, mais il y a quelques trucs à savoir, notamment sur l’enchainement des calendriers.
Ce matin, aux Rencontres Spring
, Mark Thomas a parlé du tuning de Tomcat en production. J’y ai appris plusieurs choses intéressantes que je résume ici.
Après les Rencontres Spring qui ont eu lieu aujourd’hui, nous avons eu le droit à quelques éléments de réponses à la question suivante :
Comment SpringSource va tenter de convaincre la Prod de l’intérêt de son serveur d’application, Spring DM Server ?
Sonatype propose un propre moteur de recherche dans les repository Maven. Il utilise le gestionnaire de Repo Nexus, un concurrent d’Artifactory proposé par Sonatype.
Il est accessible par : http://repository.sonatype.org
La news vient sur le blog du livre Maven The Definitive Guide.
Si celui là ne vous convient pas, il reste toujours MvnRepository (quand il est dispo…) et le repo de XooCode.org.
Les rencontres Spring ont lieu jeudi et il y aura du beau monde.
L’alléchant programme :
Merci à Julien pour l’invitation.
Suite au dernier JUG, Jérôme Louvel, l’auteur de Restlet, a bien voulu répondre à mes questions. Les sujets incluent les apports de REST, à qui il est destiné, JAX-RS et l’intégration à un existant.
Quartz est un scheduler. Il permet de lancer des Job à intervalles spécifiés ou un jour donné. Par exemple, il peut être utiliser pour réaliser des calculs à une heure où la charge serveur est faible.
Nous allons pousser un peu l’usage de Quartz pour que celui-ci fonctionne sur un Cluster. Cette configuration a l’avantage de permettre de faire du Fail-Over : si un noeud du Cluster tombe, un autre prend le relais.
Cette configuration pourrait paraître facultative mais elle est en réalité obligatoire dés que votre application est déployée sur plusieurs noeuds. En effet, comment s’assurer que chaque JVM ne démarre pas son propre Quartz ? Ainsi les scheduler ne doivent pas tous démarrer mais un seul doit être actif au même moment.
Nous sommes passés par plusieurs problèmes avec cette configuration. Je détaille ci-dessous ce qui a fonctionné pour nous. Je n’explique pas les notions de base de Quartz (trigger, calendar et job).
Hier, le JUG parisien s’est retrouvé pour une présentation de GWT et de REST-GWT.
Didier Girard s’est occupé de la première partie. Je n’aurai jamais dû l’écouter ! Maintenant je suis presque triste d’écrire du Spring MVC. J’ai l’impression de me sentir hors du coup, passé de mode. Il m’a bien fait comprendre que je devais me mettre d’urgence au toolkit de Google. Si j’ai bien retenu, GWT c’est simple, pas cher, solide, efficace, ergonomique… le graal du Web ? Pas pour tous. Flex est également bien positionné côté Java. Mais c’est un autre débat.
Si vous voulez un résumé de la soirée, le Touilleur a écrit le compte rendu de la soirée.
Pour revenir sur cette session, les juggers ont posé plusieurs questions intéressantes.
Au commencement, vous écriviez vos tests Selenium en HTML. Mais cela posait des problèmes : aucune factorisation possible, pas de setUp()/tearDown()…
Puis, vous avez commencé à écrire vos tests en Java et la vie fut plus belle. Mais cela devint verbeux et vous développiez de plus en plus de code custom pour améliorer vos tests. Et vous vous demandiez comment faire encore mieux…
Enfin, vous découvrez l’arme ultime, ce projet nommé Tellurium qui ne vous rendra certainement pas plus riche ni plus beau mais qui améliorera vos tests Selenium.
Vous l’avez compris, Tellurium est un projet qui vise à améliorer l’écriture de tests Selenium.
Ils le disent eux-mêmes :
Tellurium is more robust, flexible, modularized, easier to maintain and refactor
Qu’est-ce qu’il y a dans la boite ?
Vous aviez développé un nouveau service. Les interfaces et les données échangées étaient définies. Vous étiez optimiste, vous connaissiez bien le client. Malheureusement celui-ci utilisait de temps en temps mal votre API, vous fournissant des paramètres invalides. Vous voilà en train de corrompre l’intégrité de vos données. Pourtant même la Javadoc précisait le format des données. Avez-vous été trop optimiste ? Et votre code, comment aurait-il dû réagir ? Est-ce votre faute ou celle du client ?