Java

Maven au pays des proxys

15/01/12

Le problème…

Il y a quelques temps, j’ai eu pour mission de stabiliser et de « mavenizer » une application legacy, dont le build était devenu ingérable (dépendances dans divers répertoires, mélanges de scripts shell, Ant, etc.).

Au sujet de la mavenization elle-même, je vous recommande cet article, donnant une méthode fiable permettant de retrouver la version exacte des dépendances lorsqu’elles ne sont pas connues. Je passe cependant rapidement sur cette étape qui n’est pas le sujet ici. Nous arrivons donc directement au moment où nous avons un fichier « pom.xml » convenable, dont nous voulons vérifier le bon fonctionnement pour assurer le packaging de l’application. Et c’est là que les choses commencent à se compliquer.

Car ce que j’ai oublier de préciser, c’est que cette mission est effectuée pour « Gros client », chez qui les règles de sécurité sont strictes : l’accès internet se fait uniquement au travers d’un proxy. Et plus particulièrement le modèle PALC avec toutes les options : identification individuelle obligatoire sur ledit proxy, mot de passe à modifier tous les 3 mois, verrouillage du compte après 5 tentatives ratées, etc. Pour Maven qui aime bien « télécharger l’univers », c’est problématique.

Petite digression sur une mauvaise surprise découverte lors de cette mission… Ubuntu 11.10 n’est pas du tout adapté au travail dans un environnement utilisant un proxy : il souffre en effet d’une régression empêchant le paramétrage d’exceptions (pour les serveurs du réseau local).

Paramétrer le proxy pour Maven

Maven fournit un guide pour paramétrer un proxy. L’opération consiste à renseigner les paramètres du proxy dans le « settings.xml » :

<proxies>
  <proxy>
    <active>true</active>
    <protocol>http</protocol>
    <host>palc.grosclient.com</host>
    <port>8080</port>
    <username>user</username>
    <password>password</password>
    <nonProxyHosts></nonProxyHosts>
  </proxy>
</proxies>

Une fois ce paramétrage effectué, les dépôts sont bien résolus et les dépendances téléchargées. Mais il reste un soucis : certains dépôts irréductibles résistent encore… Par exemple le dépôt JBoss, ou encore Sonatype OSS. La cause est vite identifiée : ces dépôts utilisent le protocole « https » et non « http ».

Qu’à cela ne tienne : on duplique le bloc « proxy » en modifiant le protocole. A ceci près que ça ne marche pas… Maven ne sait utiliser qu’un seul proxy à la fois. Si on utilise le proxy « https », on pert le « http », et inversement. Peut-être une idée de correction à implémenter pour le hackergarten de mercredi prochain…

La seule solution que j’ai pu trouver à ce jour est de paramétrer les proxys au niveau de la ligne de commande :

mvn
  -Dhttp.proxyHost=palc.grosclient.com
  -Dhttp.proxyPort=8080
  -Dhttp.proxyUser=user
  -Dhttp.proxyPassword=password
  -Dhttps.proxyHost=palc.grosclient.com
  -Dhttps.proxyPort=8080
  -Dhttps.proxyUser=user
  -Dhttps.proxyPassword=password
  install

Il est possible de paramétrer un proxy dans le « settings.xml » et le deuxième en ligne de commande mais ce n’est pas très intuitif. J’aime autant que tous les paramètres soient au même endroit.

Une fois les paramètres correctement configurés, on peut les pérenniser en les enregistrant dans la variable d’environnement MAVEN_OPTS.

Utiliser un dépôt Maven interne

Suite au paramétrage correct des proxys (http et https), Maven peut à nouveau télécharger tout internet… et le build peut fonctionner. Nous pouvons donc aller plus loin et installer un dépôt Maven chez « Gros client », afin d’y publier les artefacts produits.

Cependant, ce serveur peut également servir à régler autrement notre problème de proxy. Pour cela, il y a un pré-requis : le serveur doit être accessible directement depuis le réseau de développement, et avoir accès à internet (si possible sans proxy). Dans notre cas, c’est Nexus qui fait office de dépôt Maven (mais la même technique doit fonctionner avec Artifactory ou autre…). Ensuite :

On configure différents dépôts de type « proxy » vers chacun des dépôts externes dont on a besoin.
On ajoute tous ces dépôts au dépôt groupe « public ».

Enfin, nous devons expliquer à Maven qu’il doit systématiquement utiliser notre serveur interne au lieu de tenter d’accéder directement aux dépôts externes (Maven central, etc.). Pour cela, retour dans « settings.xml », mais cette fois dans le bloc mirrors. Il suffit d’expliquer à Maven que tous les dépôts dont ont a besoin ont pour miroir notre serveur interne :

<mirrors>
  <mirror>
    <id>nexus.grosclient.com</id>
    <name>Serveur Nexus de Gros client</name>
    <url>http://nexus.grosclient.com/content/groups/public</url>
    <mirrorOf>*</mirrorOf>
  </mirror>
</mirrors>

Avec cette configuration, le paramétrage des proxys fait précédemment doit être supprimé (ou une exception doit être ajoutée pour le dépôt interne).

Cette dernière configuration présente plusieurs avantages :

L’ensemble des dépôts susceptibles d’être utilisés dans les différents projets de l’entreprise sont configurés de manière centrale, au niveau du dépôt. Cela permet ~~à l’équipe agile~~ au chef de projet (rappel : nous sommes chez Gros client) de contrôler les dépôts/librairies utilisées sur le projet.
Le premier développeur qui demande une librairie au serveur Nexus va déclencher son téléchargement depuis son dépôt initial. Mais celle-ci sera ensuite mise en cache sur le serveur. Ainsi, les appels suivants (par les autres développeurs) se contenteront d’effectuer un téléchargement sur le réseau local, avec un gain de temps (voire de bande passante) non négligeable.

Java-JEE, Maven, Proxy

99 Scala problems : les 22 premiers

9/06/11

Posté par Benoît Courtine dans Java

1 commentaire

Après quelques articles et tutoriels, ainsi que quelques tests sur les interactions avec Java, j’ai commencé mon apprentissage du Scala par les 99 Scala problems.

Avant de me lancer dans la résolution des problèmes en question, et en application des bonnes pratiques du TDD, j’ai écrit les signatures des méthodes, et les tests associés à ces 22 problèmes. Si vous voulez vous lancer, je vous épargne cette première étape : vous pouvez télécharger directement ce squelette.

Vous pourrez vérifier que les 22 tests échouent. Ces tests sont cependant rudimentaires, et les faire passer au vert ne garantira pas que vous avez la bonne solution (même si c’est encourageant).

D’autres personnes se sont lancées avant moi dans la résolution de ces problèmes. Comme il est toujours intéressant de comparer les différentes approches, en voici quelques unes (en plus des solutions du site original) :

La suite >

Java-JEE, Scala, TDD

Deuxième journée de What’s Next

27/05/11

Posté par Benoît Courtine dans Java

Aucun commentaire

Aujourd’hui, j’ai réussi à obtenir une connexion WIFI (reste à savoir pour combien de temps…). Je vais donc tenter de résumer cette deuxième journée de conférences en direct.

La journée commence de manière très conviviale, autour d’un café avec Nicolas de Loof, qui nous quittera précipitamment pour aller tester git rerere et mettre à jour sa présentation de ce soir. J’en profite pour faire la publicité des ateliers git attitude qui m’ont appris l’existence et l’utilisation de cette commande !

Keynote de Neal Gafter

Neal Gafter est une des figures emblématiques du langage Java, ayant contribué à son commencement. Il commence par nous présente un historique complet du langage, et des évènements survenus lors de son développement (problème des TCK et du projet Harmony, etc.). Au passage, quelques tests tirés de son livre Java Puzzlers (sur lesquels je me suis fait avoir : j’ai encore quelques révisions à faire…).

Nous passons maintenant à une partie qui m’intéresse : le cloud (encore !), mais à la sauce Microsoft : Azure. La plate-forme de cloud tourne en environnement Windows, mais se veut ouverte à tous les langages de développement.

Avec la plate-forme Azure, on ne s’occupe pas des machines virtuelles : la plate-forme le gère pour nous, et fournit les VMs clés-en-main, en appliquant automatiquement les patchs de sécurité, etc. Le but est de permettre aux développeurs de se concentrer sur les applications. De même, la plupart des briques techniques sont gérées automatiquement : le load-balancing, l’ajout d’une base de données, etc.

Sur ces points, la description de cette plate-forme me rappelle fortement ce que j’ai pu voir de Cloud Foundry.

Apparemment, Azure est Java Ready : SDK Java, support de JDBC4 (et donc des frameworks de persistence comme Hibernate). Il y a également un Starter Kit permettant de configurer un projet Java sur le cloud.

RabbitMQ par Rob Harrop

Pas de WIFI pendant cette présentation, j’écris le compte-rendu à postériori. Rob était absolument impressionnant (je le soupçonne d’être en fait Chuck Norris déguisé) : démonstration live sans aucun « effet démo » sur 4 langages différents (Java, Erlang, Ruby, Python) pour montrer l’inter-opérabilité de la plate-forme. Ca donne vraiment envie de l’essayer !

A suivi une phase de questions-réponses assez pointues sur la scalabilité, la résistance à la panne, les différences d’approche par rapport à d’autres technologies de messagerie, etc.

Pause déjeuner

Tirage au sort de l’iPad 2 : encore perdu… Je ne perds pas espoir d’en gagner un prochainement.

Comme hier, au Mc Donald’s d’en face, mais sans passer par la case sandwichs.

Le découplage de services par Theo Schlossnagle

Un contributeur à presque 20 projets OpenSource, ça force le respect…

Début de conférence sur les chapeaux de roue : on met les pieds dans le plat avec les raisons du choix d’une architecture NoSQL ou Cloud.

Très bonne démonstration du fait qu’on n’a pas besoin de milliers de machines pour scaler, mais de repenser son modèle dans la majorité des cas.

Le découplage d’une application en systèmes élémentaires indépendants donne de la flexibilité, mais est une opération très complexe. Elle nécessite des systèmes de files (ActiveMQ, RabbitMQ, etc.).

Pour bien concevoir un système, on doit faire la part des choses entre ce que l’on veut (un résultat instantané), et ce que l’on peut obtenir (calcul trop long pour permettre un résultat instantané). Dans ce cas, il faut découpler ce calcul dans un système asynchrone.

Conseils pour parvenir à ses fins :

Programmation défensive (timeouts, points de vérification, etc.)
Mise en place de monitoring (vitesse de traitement, taille des files d’attente, nombre de connexions concurrentes, etc.)

Si une application doit tomber en erreur, il faut qu’elle tombe en erreur rapidement (timeouts, etc.) !

Résumé final : excellente conférence pleine de très bons conseils d’architecture !

Tirage au sort des gagnants de places VIP pour Rolland Garros

Félicitations Alexandre !

Architecturer l’expérience utilisateur, par Michaël Chaize

Conférence en français (ça mérite d’être souligné).

L’architecture est impactée par l’expérience utilisateur qu’on veut donner à ses clients

Flex est devenu Open Source en 2007, et peut être codé en ActionScript 3 ou en MXML. Il génère ensuite un fichier Flash. Flex est utilisé à 90% pour des applications internes [Mode mauvaise langue]par honte de les exposer au public[/Mode mauvaise langue].

Depuis 2007, la fondation OpenScreen a permis de travailler avec les acteurs du marché mobile pour optimiser le player Flash sur les terminaux, à l’exception d’un acteur du marché qui a refusé. On se demande bien lequel…

Flex 4.5 semble effectivement assez adapté au développement mobile :

prise en compte des différentes résolutions d’écran
développement unique pour Android 2.2 et 2.3, Blackberry Playbook, et les tablettes Apple (moyennant une conversion de code)

Présentation intéressante, et qui donne envie. Mais malheureusement, je n’ai pas vraiment le temps en ce moment de faire du développement mobile (trop d’autres choses dans ma todo-list d’études).

Conférence Akka par Jonas Bonér (CTO de TypeSafe)

Il est difficile de construire des systèmes gérant correctement la concurrence et la scalabilité. Akka (et Scala) a été créé pour tenter de proposer des solutions à cette problématique.

Les trois briques principales de Akka :

Tolérance à la panne (supervision)
Scalabilité (système des Actors et clustering)
Concurrence (Actors, STM, Agents, Dataflow)

Plus tout un ensemble de modules add-on (JPA, etc.)

Qu’est ce qu’un acteur ? un acteur ressemble à un objet : c’est un état, et un comportement. Un acteur est indépendant, isolé, et ne partage pas son état : il n’y a donc pas de mécanisme de lock à implémenter pour gérer la concurrence. Les acteurs communiquent par un système de messages. Les acteurs sont indépendants des threads (à ceci près qu’un acteur est MonoThread) : la seule limitation du nombre d’acteurs est la mémoire.

L’envoi d’un message à un acteur n’attend aucun retour. Le traitement du message est asynchrone. On peut cependant attendre un résultat futur (associé à un timeout) :

actor ! message
 
val future = actor !!! message
future.await
val result = future.result

Le comportement des acteurs est complètement déterministe.

Travailler avec des acteurs distribués sur plusieurs machines est presque transparent pour le code. Le runtime fournit un mécanisme de clustering (gérant le failover) pour les acteurs, avec plusieurs stratégies de choix du serveur d’exécution (CPU utilisé, mémoire utilisée, etc.).

Elastic Search, par Shay Banon

Présentation très originale, qui s’est déroulée sans aucun slide, mais juste avec une console, et l’outil cURL, qui servait à attaquer l’API REST d’Elastic Search. Pour résumer, Elastic Search est un outil construit autour de Lucene avec les grandes fonctionnalités suivantes :

Fonctionnement en cluster (avec une gestion très simple de l’ajout d’un serveur au cluster)
API d’accès entièrement construite en REST, avec des données JSON

L’ensemble de la présentation consistait à nous montrer des fonctionnalités de plus en plus complexes :

utilisation d’un noeud, puis d’un cluster de noeuds
création d’index simples, puis complexes (en imposant un format de mapping)
recherches simples, puis complexes (filtrage, etc.)

Je n’ai encore jamais eu l’occasion de travailler sur une problématique d’indexation de documents (à l’exception d’une mise en place d’une GED Alfresco, mais où l’indexation est déjà gérée). Mais si ça devait arriver, l’API d’Elastic Search en fait un produit qui a l’air particulièrement intéressant.

L’avenir de l’intégration continue par Kohsuke Kawaguchi

La présentation commence par un bilan : la puissance des machines de développement augmente de manière exponentielle. Or, les compétences des développeurs ne suivent pas cette même évolution. Par rapport à la puissance des machines, le développeur est donc une denrée précieuse : il faut donc veiller à ce que l’outillage exploite eu mieux cette puissance machine pour permettre aux développeurs de gagner du temps.

Pour cela, plusieurs pistes :

utiliser au mieux les gestionnaires de configuration distribués (git par exemple)
faire exécuter les tests sur le serveur d’intégration continue au lieu de les exécuter sur les machines des développeurs
etc.

Epilogue

Voilà deux journées très intéressantes, sans aucun bémol majeur : c’est donc une grande réussite pour Zenika (dont je remercie toute l’équipe au passage), qui nous a d’ors et déjà invités à revenir l’année prochaine.

La soirée s’est achevée pour moi par plus d’une heure de discussions techniques passionnées sur les quais du métro avec Alexandre (rencontré hier par l’intermédiaire d’Antoine).

Félicitation à Nicolas qui a le courage de rempiler pour la soirée Jenkins… J’aurai une pensée émue pour sa présentation de ce soir (et j’en suis quitte pour un prochain article sur git, sauf si Sébastien me devance).

[Mise à jour : quelques autres compte-rendus]

[Et ça continue…]

Chez Xebia, ici et là
Chez Valtech, ici et là

Intégration Continue, Java-JEE, Veille Technologique

Première journée à la What’s Next

26/05/11

Posté par Benoît Courtine dans Java

3 commentaires

Je vais certainement manquer de temps pour résumer l’ensemble de cette journée… d’autant plus qu’on repart dès demain pour une deuxième journée de conférences toute aussi intéressante que la première.

Une logistique perfectible

Commençons par le sujet qui fâche… la logistique ! A la décharge de Zenika, c’est la première édition de la What’s Next. Et gérer la logistique pour une conférence de plus de 600 participants, ce n’est pas une mince affaire. Voici donc quelques points perfectibles :

Le Grand Rex n’a visiblement pas l’habitude de recevoir en même temps 500 geeks, tous équipés de leur {smartphone/tablette/ ordinateur portable} (rayer les mentions inutiles). Les 3 réseaux WIFI disponibles ont rapidement été saturés, et n’attribuaient plus d’adresse IP. Heureusement qu’il restait la 3G d’urgence pour couvrir l’évènement via Twitter (le hashtag officiel wsnparis ayant bien servi).
Un seul point de ravitaillement en café pour les mêmes 500 geeks, c’est l’embouteillage assuré à chaque pause (encore qu’il faille relativiser : la distribution restait suffisamment fluide, et que j’ai toujours pu avoir mon café).
Le déjeuner a convaincu une bonne partie des participants de se retrouver au Mc Donald’s d’en face. Cependant, vu le rapport entre le prix d’entrée et la qualité des conférenciers présents, je ne regrette pas le déjeuner un peu léger. J’aime autant que la conférence reste à prix abordable, quitte à devoir sacrifier sur la nourriture.

Le choix du Grand Rex a pourtant un certains nombres d’avantages indéniables :

bien placé, au centre de Paris
des sièges bien plus confortables que dans la majorité des salles de conférences

Une ambiance géniale et des rencontres très sympatiques

Comme d’habitude, la journée a été très riche en rencontres. Outre les personnes déjà croisées au Paris JUG (ou autres évènements), j’ai pu faire la connaissance aujourd’hui de David Gageot, Nicolas de Loof, Arnaud Héritier, Florian Boulay, ainsi qu’un bon nombre d’autres personnes…

L’ambiance générale de l’évènement était très agréable : très détendue, très geek (sur l’ensemble des participants, on n’a pu dénombrer que quelques cravates). Sur ce sujet, la palme revient d’ailleurs certainement à Jevgeni Kabanov.

Enfin, la fin de journée sur une discussion autour d’une bière était une super-idée pour permettre un debriefing et des débats passionnés dans une bonne ambiance, même si j’ai dû m’absenter assez rapidement, étant attendu.

De très bonnes conférences

Les conférences étaient très bonnes. Parmi celles-ci, j’ai particulièrement apprécié :

La keynote d’Adrian Colyer, où il était question surtout question de cloud, de cloud… et de cloud ! Cette conférence m’a donné envie de me repencher sur Cloud Foundry, après quelques premiers tests. Au passage, on notera l’apparition d’un nouveau buzzword qui devrait faire fureur dans les prochaines : le microcloud (j’aurai peut-être l’occasion de revenir sur ce concept dans un prochain article).
La présentation du projet Eclipse Orion, par Boris Bokowski. Elle ne m’a pas convaincu d’abandonner IntelliJ IDEA, mais la démonstration des possibilités d’édition était impressionnante : on ne se croirait pas dans une application web ! Parmi mes appréhension, je me pose en particulier la question suivante : l’IDE web est-il résistant à la perte de la connexion réseau et permet-il de travailler offline ?
La présentation de Clojure par Howard Lewis Ship était intéressante : elle rappelait bien les différents paradigmes de la programmation fonctionnelle. Cependant, le langage lui-même ne m’a pas du tout convaincu : les exemples de code étaient particulièrement difficiles à relire, et me rappelaient la syntaxe sur-parenthésée du LISP. Sur les langages fonctionnels, je vais donc certainement continuer de faire l’impasse sur Clojure, et poursuivre ma découverte de Scala.
La présentation de Jevgeni Kabanov sur la gestion de la mémoire en Java était passionnante. En particulier, la modélisation du CPU et de la gestion mémoire par du code Java était impressionnante ! En résumé, un excellent cours de culture générale sur la gestion de la mémoire en Java. Pour revoir cette conférence (éventuellement au ralenti), c’est dans l’ordre ici, ici, et ici.
Enfin, la présentation des Web Sockets parBrad Drysdale m’a là encore donné envie d’étudier cette API de plus près. Par chance, je me souviens avoir lu rapidement un article parlant des Web Sockets et de Play Framework.

Après cette conférence, je sens que je vais avoir un programme d’étude chargé ces prochains week-ends… Vivement demain pour la suite !

[Mise à jour] Pour un résumé beaucoup plus détaillé de cette première journée, conférence par conférence (et avec des photos), foncez chez Nicolas.

Java-JEE, Veille Technologique, What's Next

Premiers pas en Scala

24/05/11

Posté par Benoît Courtine dans Java

4 commentaires

Cela fait maintenant pas mal de temps que j’entends parler de Scala, mais je n’avais jamais pris le temps m’y attarder. Il y a maintenant deux semaines, l’annonce du lancement de Typesafe (on pourra lire l’article de Nicolas pour plus d’informations) m’a donné envie de regarder de plus près ce langage.

En attendant mon prochain passage par la FNAC pour trouver un bon livre sur la question, j’ai été glaner quelques informations pour débuter :

La liste des billets de Nicolas sur la question
Les 99 Scala Problems, que je suis en train de faire petit à petit
Les différents liens de documentation du site officiel (il y a de quoi faire…)

J’ai eu la chance d’avoir des cours de Caml Light en prépa et de Lisp en école d’ingénieurs : la programmation fonctionnelle ne m’est donc pas inconnue, ce qui m’a grandement facilité l’entrée en matière (même si j’ai rapidement dû me mettre à niveau avec les Case Class et autres concepts que je n’avais encore jamais rencontré).

Les cours de prépa que j’ai pu avoir sur la question étaient excellents. Même s’ils concernent le langage Caml, ils fournissent des exemples originaux dans lesquels la programmation fonctionnelle permet de s’en sortir bien plus facilement qu’en programmation procédurale. Je propose donc aux curieux d’aller les consulter sur le site de notre enseignant.
La suite >

Java-JEE, Maven, Scala

PlayFramework et CloudFoundry RELOADED

5/05/11

Posté par Benoît Courtine dans Java

3 commentaires

L’informatique bouge décidément très vite !… A peine quelques jours et mon précédent article est déjà obsolète. Voici donc sa mise à jour.

Problèmes de fixtures

Revenons tout d’abord aux problèmes que j’ai rencontré avec la classe Fixtures, qui provoquaient deux erreurs lors du déploiement de l’application sous forme de WAR. Il s’agissait d’un bug spécifique à la version 1.2 de PlayFramework. Or avant même que j’aie le temps de le temps de dire ouf, la version 1.2.1 était publiée (une journée après mon article), corrigeant le bug en question !

J’ai depuis revérifié mon exemple : plus aucun problème de ce côté. Il est donc possible de déployer l’application YABE sur Cloud Foundry sans avoir à modifier la moindre ligne de code.

cd $PLAY_HOME/samples-and-tests
play war yabe -o yabe_war
cd yabe_war
jar -cvf yabe.war *
rm -rf WEB-INF
vmc push

Ca marche !

Utilisation du service MySQL de CloudFoundry

De ce côté là aussi, les choses ont bougé. Je me suis attelé à la tâche en créant un plugin dédié, dont le code (et les binaires) est disponible sur GitHub. Bon, je n’ai pas beaucoup de mérite : le plus gros du travail a été fait par SpringSource, avec le cloudfoundry-runtime.

Ca a été pour moi l’occasion de me familiariser vraiment avec une des nouvelles fonctionnalités de PlayFramework : la gestion des dépendances Maven. Voici à titre d’exemple le fichier dependencies.yml du plugin :

self: play -> cloudfoundry 0.1
require:
    - play
    - org.cloudfoundry -> cloudfoundry-runtime 0.6.0:
        exclude:
            - org.springframework -> *
            - org.springframework.amqp -> *
            - org.springframework.data -> *
            - org.apache.tomcat -> *
            - commons-dbcp -> *
repositories:
    - spring_milestone:
        type: iBiblio
        root: http://maven.springframework.org/milestone
        contains:
            - org.cloudfoundry -> *

Cette librairie effectue le travail de lecture et de parsing des variables d’environnement. Il suffisait donc ensuite de se servir des résultats de se parsing pour configurer la connexion à la base de données.

Cette fois, c’est le PlayFramework lui-même qui va nous simplifier la tâche. Les plugins peuvent surcharger la méthode onApplicationStart(), qui s’exécute comme son nom l’indique au démarrage de l’application.

public class CloudFoundryDBPlugin extends PlayPlugin {
    @Override
    public void onApplicationStart() {
        Properties p = Play.configuration;
        MysqlServiceInfo mysqlServiceInfo = getInfoFromCloudFoundryRuntimeLib();
        p.put("db.driver", "com.mysql.jdbc.Driver");
        p.put("db.url", mysqlServiceInfo.getUrl());
        p.put("db.user", mysqlServiceInfo.getUserName());
        p.put("db.pass", mysqlServiceInfo.getPassword());
    }
}

Et c’est tout. Pour utiliser ce plugin, il suffit d’ajouter le module correspondant dans l’application PlayFramework que l’on veut déployer sur Cloud Foundry, soit dans application.conf :

1
2
3

# Replace ce memory db by the cloudfoundry MySQL service
# db=mem
module.cloudfoundry=${play.path}/modules/cloudfoundry

Encore une fois, c’est tout : la magie de PlayFramework se charge du reste !

Il n’y a plus qu’à régénérer le WAR et mettre à jour l’application : ça marche, comme en témoigne l’application mise à jour http://yabe.cloudfoundry.com/

Et maintenant…

Le plugin ne gère pour l’instant que la configuration automatique d’un service MySQL de Cloud Foundry. Mais si des spécialistes de Redis, MongoDB veulent donner un coup de main pour gérer ces bases, les merge request de GitHub sont là pour ça.

Cloud Computing, Cloud Foundry, Java-JEE, Play! framework

Application Play Framework sur Cloud Foundry

1/05/11

Posté par Benoît Courtine dans Java

2 commentaires

Il y a quelques semaines, j’ai obtenu un accès à la béta de Cloud Foundry. Pour ceux qui n’ont pas suivi l’actualité, il s’agit d’un PaaS (Platform as a Service) Open Source de VMWare, permettant d’exécuter en cloud des applications Java (WAR, Spring, ROO), Rails, ou Node.js (pour l’instant, mais d’autres pourraient bientôt venir enrichir cette liste).

Prise en main

La prise en main de l’outil de déploiement VMC via le tutoriel est extrêmement simple. On y apprend à créer et déployer une application sur le cloud en quelques commandes.

Deuxième chose à laquelle je m’intéresse, les systèmes de persistance. On a le choix entre trois systèmes, SQL (MySQL) ou NoSQL : MongoDB (base orientée documents) et Redis (base clé-valeur). Cette liberté de choix est très appréciable, et permet de répondre aux différents types de besoins que l’on peut avoir. Et là encore, on peut penser que d’autres systèmes viendront prochainement enrichir cette liste.

Côté Java, encore de bonnes surprises : contrairement au Google App Engine (par exemple), il n’y a aucune restriction sur l’utilisation de l’API : l’application est exécutée sur un serveur Tomcat. Il est donc possible de développer une application web Java complètement standard, et ensuite de la déployer sur Cloud Foundry au lieu d’un serveur d’application classique.

J’ai fait le test (avec une application simple) et ça fonctionne !

Avec Spring et l’outil de développement Spring Tool Suite, la gestion de la persistence MySQL est très simple, comme expliqué sur le blog officiel.
La suite >

Cloud Computing, Cloud Foundry, Java-JEE, MySQL, Open Source, Play! framework, SI

Allons plus loin avec les services REST

25/02/11

Posté par Benoît Courtine dans Java

Aucun commentaire

Le « Hello World« , c’est bien… mais vite limité pour une véritable application.

Avant toute chose, voici la page wiki de Sun qui m’a servi de référence pour connaître les différentes possibilités de la JSR-311. Voici une petite présentation de mon cheminement au travers de ces fonctionnalités :

Les « query params »

Pour construire des services utilisables, il faut pouvoir leur passer des paramètres. La première idée qui m’est venue à l’esprit est d’utiliser des paramètres POST ou GET (souvenirs du temps où je faisais du PHP…). Dans les deux cas, c’est très simple. Il suffit d’annoter le paramètre avec @QueryParam :

@GET
@Produces("text/plain")
public void helloName(@QueryParam("name") String name) {
    return "Hello " + name;
}

On peut immédiatement tester le résultat à l’adresse « http://serveur/ws/hello?name=Benoit« . On peut rajouter à chaque paramètre une annotation @DefaultValue(« World »).
La suite >

Java-JEE, Open Source, REST, Web Services

RESTiser une application simplement

14/02/11

Posté par Benoît Courtine dans Java

5 commentaires

J’ai travaillé récemment sur une ancienne application web Java (Struts + Hibernate), n’utilisant ni ne consommant aucun service web. Dans le plan de désengagement de cette application, il était prévu que l’IHM Struts soit désactivée, mais qu’elle fournisse (sous forme de services web) ses fonctionnalités à sa remplaçante, en attendant que cette dernière implémente elle-même ces fonctions.

SOAP n’étant plus trop à la mode ces derniers temps, nous avons décidé de réaliser cette évolution en utilisant des services REST. J’écris ce petit article afin de faire part de ce retour d’expérience de « RESTisation », qui s’est avérée être une opération particulièrement simple.

Mavenizer l’application

La première étape de ce processus a été de remplacer les anciens scripts de build par Maven. Même si l’application est « en fin de vie », le rapport gain/temp passé justifie largement l’investissement : déploiement simple dans un environnement d’intégration continue Hudson Jenkins, automatisation des tests, vérification des métriques qualité avec Sonar, etc.

Pour cette phase, je vous renvoie à l’excellent article « Mavenizer un projet« , de Nicolas de Loof.

Créer la servlet de services REST

Après une première vérification, le serveur d’application hébergeant cette application n’implémente pas la JSR-311. Nous allons donc ajouter au projet la dépendance Jersey, implémentation de référence de cette JSR. Comme notre projet a été préalablement mavenizé, il suffit d’une nouvelle dépendance dans le pom du projet :

<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-server</artifactId>
    <version>1.5</version>
    <scope>compile</scope>
</dependency>

[Mise à jour le 24/02/2011] Personne ne m’a fait la remarque, mais la dépendance « jersey-server » ne se trouve pas dans le dépôt « Maven Central« . Je ne m’en suis aperçu que tardivement, car mon settings.xml contient un certain nombre de dépôts complémentaires. En l’occurrence, celui qui nous intéresse pour cette dépendance est le dépôt de java.net :

<repository>
    <id>javanet</id>
    <name>Repository for Maven2</name>
    <url>http://download.java.net/maven/2</url>
</repository>

[Fin de mise à jour]

Ensuite, dans à côté de la servlet Struts, nous ajoutons une nouvelle servlet Jersey qui sera chargée de traiter les requêtes vers nos futurs services. Nous la paramétrons immédiatement en lui indiquant dans quel package elle doit chercher les classes de service. Ce paramètre d’exemple est spécifique à Jersey, et il faut évidemment l’adapter à la servlet utilisée dans votre projet :

<servlet>
    <servlet-name>struts</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <param-name>config</param-name>
        <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet>
    <servlet-name>jersey</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <init-param>
        <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>org.courtine.oldappli.ws</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
</servlet>

Il ne nous reste plus qu’à créer le mapping pour indiquer quelles requêtes seront traitées par cette nouvelle servlet :

<servlet-mapping>
    <servlet-name>struts</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>jersey</servlet-name>
    <url-pattern>/ws/*</url-pattern>
</servlet-mapping>

Créons notre premier service

La servlet étant en place, nous allons créer un premier service dans le package configuré ci-dessus, afin de s’assurer que la servlet fonctionne. Voici le code de ce service :

package org.courtine.oldappli.ws;
 
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
 
/**
 * Test du bon fonctionnement de la servlet "Jersey".
 */
@Path("/hello")
public class TestWS {
 
    @GET
    @Produces("text/plain")
    public String helloWorld() {
        return "Hello World";
    }
}

Il n’y a plus qu’à tester

C’est tout… Il n’y a rien d’autre à faire pour que notre service fonctionne. Pour s’en convaincre, il suffit de déployer cette nouvelle application dans son serveur de test (Tomcat, Jetty, etc.), et (en supposant que le serveur écoute sur le port 8080) d’accéder à l’adresse « http://localhost:8080/ws/hello » dans son navigateur. Si tout c’est bien passé, le traditionnel message « Hello World » s’affiche.

Le test étant concluant, on peut passer aux choses sérieuses et développer de vrais services…

Java-JEE, Open Source, REST, Web Services

Revue de presse…

6/02/11

Posté par Benoît Courtine dans Java

Aucun commentaire

L’emménagement s’est bien passé, et la nouvelle Freebox est arrivée beaucoup plus vite que prévue. Cependant, nous sommes toujours occupés à finir les petits travaux d’installation qui ne me laissent pas beaucoup de temps pour écrire, en particulier à cause des préparatif pour l’implémentation d’ici un mois de l’interface suivante :

public interface Bebe {
 
  public String getNom();
 
  public String getPrenom();
 
  public Sexe getSexe();
 
  public double getTaille();
 
  public double getPoids();
}

A défaut d’avoir le temps d’écrire un article de fond, voici donc en vrac une revue rapide de ma veille de ce mois de janvier…

LibreOffice vs OpenOffice

C’est finalement LibreOffice qui a sorti le premier sa version 3.3.0, ce à quoi Oracle a répondu quelques jours plus tard avec la même version de sa suite. Après un test rapide de ces deux versions, la différence de fonctionnalités n’est pour l’instant pas flagrante. OpenOffice étant beaucoup plus agréable graphiquement, je vais donc rester sur la suite d’Oracle en attendant la suite des évènements…

Hudson vs Jenkins

Deuxième fork, encore une fois avec un produit d’Oracle, encore une fois pour des différents sur la gouvernance du projet. C’est la solution d’intégration continue Hudson qui a été forkée par sa communauté (et son fondateur, Kohsuke Kawaguchi). Comme pour OpenOffice, Oracle décide de poursuivre de son côté le développement d’Hudson, avec le soutien de Sonatype. Pour ma part, j’ai décidé de « switcher », et de suivre le projet Jenkins.

Play Framework

La version mineure 1.1.1 de Play Framework est parue ! Mais la grande évolution, c’est la version 1.2 prévue pour mars. Jusqu’à maintenant, lorsqu’on voulait ajouter une librairie à un projet Play, il fallait la mettre dans le répertoire « lib », et donc commiter celui-ci avec le reste du projet.

Habitué aux projets Maven, où les dépendances sont gérées dans un unique fichier de configuration (et donc où les binaires de ces dépendances ne sont pas mis en gestion de configuration), je n’appréciait pas ce fonctionnement de Play, malgré ses autres qualités.

Or, avec la version 1.2 qui arrive, on va avoir un fonctionnement similaire à celui de Maven, où on va pouvoir définir des dépôts et lister les dépendances dans un fichier de configuration.

Paris JUG

Lundi 28 février aura lieu à la cité universitaire le 3ème anniversaire du Paris JUG : au programme, « siffler en travaillant » ! Et tant qu’on est dans l’annonce d’évènements Java, les 26 et 27 mai auront lieu au Grand Rex le « What’s Next Paris?« .

Software craftmanship

Le « software craftmanship », c’est le concept à la mode (avec les TDD, Scrum, et autres DevOps). Sur ce sujet, je tenais à signaler le dernier billet de Nicolas Martignole, auquel j’adhère totalement.

Java

Le problème…

Paramétrer le proxy pour Maven

Utiliser un dépôt Maven interne

Keynote de Neal Gafter

RabbitMQ par Rob Harrop

Pause déjeuner

Le découplage de services par Theo Schlossnagle

Tirage au sort des gagnants de places VIP pour Rolland Garros

Architecturer l’expérience utilisateur, par Michaël Chaize

Conférence Akka par Jonas Bonér (CTO de TypeSafe)

Elastic Search, par Shay Banon

L’avenir de l’intégration continue par Kohsuke Kawaguchi

Epilogue

Une logistique perfectible

Une ambiance géniale et des rencontres très sympatiques

De très bonnes conférences

Problèmes de fixtures

Utilisation du service MySQL de CloudFoundry

Et maintenant…

Prise en main

Les « query params »

Mavenizer l’application

Créer la servlet de services REST

Créons notre premier service

Il n’y a plus qu’à tester

LibreOffice vs OpenOffice

Hudson vs Jenkins

Software craftmanship

Mes réseaux

Publicité

Blogs personnels

Détente

Open Source

Sociétés