Article publié par Pablo Lopez le 16 avril 2010.
Catégorie(s) : Exploitation, Java / JEE, Performance
3ème épisode de notre série. Il est temps pour notre magnifique application de dépasser la barre symbolique de l’utilisateur unique. Mais comme nous nous sentons confiants et forts, nous allons pousser le vice de passer à, tenez vous bien, 5 utilisateurs concurrents. Et comme certains diraient, « Et là, c’est le drame ». Les temps se dégradent à vitesse grand V.
Article publié par Xebia France le 1 avril 2009.
Catégorie(s) : Divers
Voici la liste des billets les plus lus sur ce blog en janvier, février et mars :
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n’a, en principe, pas de rapport avec le processus de développement ou les pratiques d’ingénierie utilisée dans la réalisation du projet. Il s’agit simplement, dans l’esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison. Dans un État de droit, et pour autant qu’elles ne soient pas abusives, ces dispositions contractuelles ont force de loi, et protègent efficacement les parties prenantes.
A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.
Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.
Vous avez peut-être assisté au Paris JUG sur GWT et vous vous êtes forcément dit en sortant de la conférence qu’il fallait absolument vous mettre à GWT. En plus, le pas à franchir n’est pas énorme : c’est du Java (ça devrait aller), agrémenté de nombreuses librairies comme dans le monde J2EE, des libraires graphiques qui en jettent sont disponibles… Que d’avantages ! Mais par où commencer ?
Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques.
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.
Article publié par Séven Le Mesle le 12 février 2009.
Catégorie(s) : Java / JEE
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.
Article publié par Xebia France le 27 octobre 2008.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Article publié par Benoit Moussaud le 19 mars 2008.
Catégorie(s) : Java / JEE
En mai 2007, Manuel Eveno expliquait comment avec la programmation orientée aspect (AOP) et l’outil Jamon, il est facile de relever des points de mesure dans une application Java / J2EE. Cependant, il existe des situations (exemple : environnement de Production) où l’on aimerait pouvoir activer temporairement ou désactiver complètement ce type d’aspects. Dans cet article, je vais expliquer comment avec l’AOP on peut activer un aspect par JMX.
Article publié par Benoit Moussaud le 28 juin 2007.
Catégorie(s) : Java / JEE
JConsole est un outil disponible à partir du JDK 5.0 qui repose sur l’API JMX pour afficher et suivre les métriques d’une machine virtuelle Java.
Les différentes catégories sont :
Il existe deux façons de connecter une JConsole sur une machine virtuelle Java 5 :
Article publié par Benoit Moussaud le 9 mai 2007.
Catégorie(s) : Java / JEE
Dans un post précédent, j’ai expliqué comment exposer un MBean avec Spring dans WebLogic Server 8.1. Je vais vous montrer comment interagir avec ce MBean avec WLST.
WebLogic Scripting Tool (WLST) est un outil en ligne de commande qui permet de surveiller et gérer des instances WebLogic Server. Cet outil de scripting est basé sur le langage Jython[1], une implémentation du langage Python 100% Java. A l’origine, cet outil a été développé pour WebLogic 8.1.x. Il est disponible en version 5.4 [2] sur le site CodeShare, le repository des projets open source liés au monde des serveurs WebLogic. A partir de la version 9.0 de WebLogic Server, WLST a été intégré à la distribution et est complètement supporté par BEA.
Avec WLST il est possible :
Article publié par Benoit Moussaud le 21 février 2007.
Catégorie(s) : Java / JEE
La spécification liée aux extensions de management, plus connue sous le nom de JMX est l’un des plus ancienne du JCP. Elle porte le n°3. Cependant, elle n’a été validée qu’en Juillet 2000 et communément utilisée que très récemment. Il a fallut attendre les serveurs d’application J2EE 1.4 ou le JSE 5 pour voir cette technologie devenir massivement diffusée en version 1.2. Auparavant chaque éditeur proposait sa propre implémentation avec des versions incompatibles entre elles.
Le serveur d’application WebLogic 8.1 utilise massivement cette technologie pour permettre de configurer et monitorer les serveurs. La console d’administration n’est qu’une interface graphique à ces MBeans (Management Bean). Cependant il peut être intéressant d’exposer des MBean supplémentaires :
Voici donc les étapes à suivre et les pièges à éviter pour exposer un MBean avec le framework Spring 2.0 dans WebLogic 8.1. L’environnement de développement est Eclipse 3.2 avec WTP.
Complet
Twitter
