Voici la configuration que j’applique lorsque mon poste de développement se situe derrière un proxy ultra-restrictif. Je pars du principe que vous êtes dans une entreprise, donc vous avez hélas un poste sous Windows.
Le principe est d’utiliser plink au lieu de la commande ssh fournie par défaut par msysgit.
Plink va permettre d’utiliser une clef stockée par pageant et de faire un tunnel SSH vers le repository git.
Dans cet article, je vais vous montrer comment créer une application Play! et comment la déployer sur Google AppEngine.
Google AppEngine (GAE) propose une solution d’hébergement d’applications gratuites très pratiques pour des applications Java. La liste des fonctionnalités offertes par GAE peut-être consultée ici.
Le framework Play! fournit un module extrêmement bien fait pour déployer des applications sur Gae et un autre module est disponible pour gérer le Datastore Gae : Siena.
Continuer a lire »
Voici un billet un peu plus pratique utilisant le framework Play!.
Contrairement à mon billet précédent, celui-ci s’adresse avant tout aux développeurs.
L’objectif est d’intégrer dans une page un éditeur de texte riche au format Textile. Cette syntaxe est très simple à appréhender et la génération de code HTML à partir de code Textile est native dans Play! grâce à la librairie Wikitext.
En ce qui concerne l’éditeur en tant que tel, nous allons utiliser l’excellent MarkItUp. Il est basé sur jQuery, lui même nativement embarqué par Play!. MarkItUp propose un éditeur modulaire, permettant de gérer plusieurs syntaxes. L’ajout de syntaxes se fait par des sets.
Depuis le 2 novembre, la version 1.1 du framework Play! est disponible.
Je ne vous ferai pas une présentation de ce framework, il en existe plusieurs dont celle du Touilleur Express (Play! Framework).
Je vais plutôt vous faire un retour d’expérience de la mise en place des outils nécessaires pour intégrer des applications Play! à notre usine d’Intégration Continue.
Continuer a lire »
JMX (Java Management Extensions) est très pratique pour le monitoring d’une application.
Malheureusement, lorsque l’application grandit et que, par exemple, des traitements nocturnes apparaissent, ces derniers tournent dans des machines virtuelles distinctes.
A ce moment là, JMX pose problème pour la remontée d’informations.
L’idée que je vais vous proposer est la suivante :
Après avoir étudié les différents frameworks Java en vue de la génération de documents PDF (ici), entrainons-nous maintenant 2 exemples simples d’implémentation de la librairie iText.
Ce sample se divise en 2 parties :
Il existe diverses outils pour générer ou travailler sur des fichiers PDF de nos jours.
Intéressons-nous plus particulièrement aux librairies Java permettant de générer ou de parser des PDF sans avoir besoin d’un quelconque outil d’Adobe.
Continuer a lire »
Suite à la mise en place de Spring Batch 2.1 chez un client, voici quelques recommandations afin d’éviter une catastrophe technique.
Il faut savoir que Spring Batch a été développé dans la logique des Batchs tels qu’ils existaient dans les gros systèmes : un Batch est une répétition en très grand nombre d’opérations unitaires (work unit).
Le mode de fonctionnement de Spring Batch est très lié à ce modèle.
Il est donc complètement inutile de se lancer dans l’implémentation de ce framework si l’organisation de votre traitement ne suit pas ce modèle.
Je pense notamment à des traitements qui executeraient des updates SQL massifs : il ne sert à rien de construire une suite de Steps qui lanceront chacunes un update massif. Il faut construire une Step unique qui lancera un traitement complet sur un élément unitaire (appelé chunk dans le langage Spring Batch).
Pour bénéficier de la puissance de Spring Batch, il est important que votre couche de persistance soit homogène : elle doit être full Hibernate, full iBatis ou full Spring JDBC et ne pas comporter d’éléments ‘homemade’.
La gestion des transactions dans le batch est déléguée au TransactionManager, le développeur n’a plus la main dessus.
Attention !
Si vous souhaitez multithreader des requêtes potentiellement longues avec Spring Batch, il vous faudra mettre en place du JTA. En effet, votre TransactionManager va devoir gérer une transaction ‘chapeau’ qui gèrera elle-même une transaction par thread.
D’où JTA. Ceci est dû au fait qu’une connection à la base de données ne peut pas être accédée simultanément par plusieurs threads (l’objet Connection n’est pas thread-safe).
Lorsque l’on utilise Eclipse et Maven, il est très courant d’utiliser le plugin Maven Eclipse.
Je ne compte plus les fois où je dois travailler avec plusieurs versions d’un même projet Eclipse dans le même workspace Eclipse. Or Eclipse interdit d’importer 2 fois un projet du même nom.
Voici un paramètre du plugin permettant de choisir le nom du projet Eclipse généré à partir de Maven :
mvn -Declipse.projectNameTemplate=[artifactId]-1.3 eclipse:eclipse
Cette commande va créer un projet nommé toto-1.3 où toto est le nom du projet maven.
Vous pouvez aussi utiliser les balises [groupId] et [version].
