Excilys Labs

AngularJS et Spring Data MongoDB

Rémy Francillette — Tue, 23 Apr 2013 12:53:18 +0000

Si vous vous êtes intéressés par AngularJS et MongoDB, allez faire un tour sur ce repository : https://github.com/rfrancillette/shopping-list. Vous y trouverez une petite démonstration de l’intégration de ces deux technologies pour créer une application de liste de courses.

Coté serveur, grâce Spring Data, Spring MVC et Jackson, l’application expose des données stockées dans MongoDB sous forme de web services REST. Coté client, il y a peu d’ HTML5, de Bootstrap et AngularJs avec sa gestion des ressources REST.

Bonne lecture

Et pour plus d’infos :

Eclipse ResourceBundle Editor Plugin

Baptiste Pagnier — Wed, 26 Dec 2012 09:13:06 +0000

Il est souvent fastidieux de gérer plusieurs fichiers ResourceBundle pour internationaliser un projet :
- Les clés ne sont pas triées,
- Il est difficile de savoir quel message est présent pour quelle langue, quelles sont les clés manquantes ou en double,
- On doit jongler entre les fichiers à chaque insertion / modification / suppression de clé,
- …

Que fait l’outil ?

Eclipse ResourceBundle Editor est un petit plugin très simple qui facilite beaucoup cette tâche !
Il permet de tout faire dans un même écran, et possède de nombreuses fonctionnalités très pratiques :
- Les clés sont triées (ordre alphabétique ou par hiérarchie de groupe)
- La recherche est simple (possibilité de filtrer les clés affichées)
- Les clés manquantes ou en double sont marquées d’un petit icone,
- Il est possible de renommer et de supprimer des groupes de clés,
- Les caractères non ASCII sont convertis vers de l’unicode
- Les fichiers sont réorganisés proprement
- …

De plus l’outil est assez personnalisable, via le menu des préférences Eclipse.

Ce plugin n’avait pas eu de mise à jour depuis plus de 5 ans, mais une nouvelle version est sortie ce mois-ci !
Elle corrige de nombreux bugs, améliore les performances et ajoute des fonctionnalités bien pratiques comme par exemple le filtre sur les propriétés affichées.

Installation

Pour l’installer c’est très simple, il suffit de télécharger le plugin en cliquant ici, puis de déplacer le contenu du .zip dans le dossier /plugins/ de votre installation Eclipse (C:/Program Files/eclipse/plugins/ par exemple).
Un redémarrage d’Eclipse, et c’est terminé !

Il fonctionne sur les version 2.x, 3.x et 4.x d’Eclipse.

Petite remarque : dans les préférences, certains messages ne sont pas traduits, et la clé est affichée à la place du message, … amusant pour un outil d’édition de ResourceBundle !

Site officiel : http://eclipse-rbe.sourceforge.net/index.htm

Smock, ou comment tester un webService

Audrey Romanet — Wed, 12 Dec 2012 13:31:42 +0000

Dans le cadre de ma mission actuelle, je devais réécrire quelques webservices qui utilisaient de vieilles librairies pas forcement adaptées au mapping XML (Castor, en l’occurence…).
Sauf que, bien sûr, je n’avais pas le droit de tout casser (quelle surprise !), et j’ai donc dû m’assurer que le contrat du webservice n’était pas rompu, et en particulier que le mapping XML du webservice mappait toujours les classes de la même façon. Je vais donc vous parler d’une librairie bien utile pour cela : Smock.

Smock teste les “entrées/sorties” d’un webservice : on lui donne un XML en entrée, il l’envoie au webservice, et il nous rend le XML de sortie. On peut donc s’assurer que l’interface du webservice n’est pas modifiée.

On se retrouve au final à écrire quelque chose d’assez simple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import net.javacrumbs.smock.http.cxf.server.servlet.AbstractSmockServerTest;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:test-appContext.xml"})
public class WebServiceTest extends AbstractSmockServerTest {

@Value("wsPath")
String wsPath;

@Test
public void getPersonByUid(){
sendRequestTo(wsPath, withMessage("GetPersonByUid/GetPersonByUidRequest.xml"))
.andExpect(message("GetPersonByUid/GetPersonByUidResponse.xml"));
}
}

Le webservice est déclaré dans la config Spring comme d’habitude, ce qui permet de soit faire un test d’intégration vraiment complet, soit mocker les services et tester uniquement la partie “mapping” du webservice.

On a également la possibilité d’écrire des requêtes et/ou réponses XML modulables, en utilisant le GroovyTemplateProcessor.

1
2
3
4

sendRequestTo(WS_PATH,
withMessage("GetPersonByUid/GetPersonByUidRequest.xml")
.withParameter("uid", uid))
.andExpect(message("GetPersonByUid/GetPersonByUidResponse.xml"));

Cette librairie m’a permis entre autres de me rendre compte que j’étais en train de modifier les namespaces de mes objets, par exemple…

Gatling in the sky with diamonds

Bastien L. — Mon, 03 Dec 2012 09:01:24 +0000

Gatling est un projet open-source lancé en 2011 et sponsorisé par eBusiness Information. Il s’agit d’un outil de stress d’application nouvelle génération, visant à être beaucoup plus performant que les standards du marché. Ceci est rendu possible en tirant parti des processeurs multicores et d’I/O non bloquantes, grâce à Akka et AsyncHttpClient/Netty notamment.

Alors quoi de neuf ? Et bien Gridinit a annoncé le 29 novembre dernier le support de Gatling pour ses utilisateurs payants et ses bêta-utilisateurs.

Gridinit est un SaaS (Software as a Service) qui propose une collection d’outils pour réaliser des tests de performances. Cela va du test de charge basique sur une URL à l’exécution d’un plan plus complexe grâce à des simulations JMeter. Les outils sont déployés dans le cloud, principalement sur des instances Amazon Web Services, ce qui permet de réaliser des tests de performances sans avoir à investir dans des machines coûteuses ou de disposer de nœuds à l’extérieur du SI, voire tout autour du globe. On va donc pouvoir dès à présent lancer des tests de charge Gatling dans les nuages.

Gridinit : tableau de bord

Plutôt une bonne nouvelle quand on sait que Altentee, la société derrière ce SaaS, est relativement active sur JMeter qui représente actuellement son coeur de marché. Pour autant Gridinit semble être à l’affût des avancées dans le monde des tests de performances. En effet quand on facture à ses clients des nœuds/heures, c’est à dire des ressources, on aimerait pouvoir leur offrir le meilleur rapport ressource/performance.

Gridinit : injecteurs supportés

Or l’arrivée d’outils utilisant des moteurs asynchrones basés sur le modèle des acteurs, comme Gatling, a permis d’obtenir des gains de performance non négligeables par rapport aux solutions précédentes basées sur le principe d’un utilisateur = un thread. Dans cette optique proposer une solution permettant d’utiliser au mieux les ressources mises à disposition fait sens. Gridinit a ainsi publié sur son blog une vidéo démontrant la puissance de Gatling en réalisant un test de charge avec 50k utilisateurs et 5k requêtes/sec en 5 minutes avec seulement 8 nœuds sur les 160 qui sont utilisables.

D’ailleurs Gridinit annonce la possibilité de lancer en moyenne 20 000 utilisateurs sur un noeud avec Gatling, quand JMeter permet seulement 1000 utilisateurs en moyenne. On peut donc espérer diviser par 20 ses coûts dans un tel contexte.

Gridinit : Gatling vs Jmeter

Sources :

Un simple POJO !

Yassine Ben-Khaled — Fri, 02 Nov 2012 11:05:45 +0000

Chez le client, j’interviens depuis peu sur un autre projet.
Pour ne pas rentrer dans les détails, je me retrouve à créer des vues de paramétrage pour certaines tables qui étaient jusqu’ici alimentées à la main par requêtes SQL

Je me lance sur un petit test (juste de l’affichage !) sur une seule entité (et j’ai choisi la bonne ).

Voici l’entité :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class TypePrime implements XXX {

private Integer id;
private String code;
private String libelle;
private Boolean calculee;

/*...*/

public Boolean isCalculee() {
return this.calculee;
}

public void setCalculee(Boolean calculee) {
this.calculee = calculee;
}
}

Je me rends sur la page de test, et là surprise ! Exception !
(On utilise du JSF.)

javax.faces.el.PropertyNotFoundException: /faces/parametrage/tableau-prime.xhtml @27,101
value="#{parametre.calculee}": Bean: xxx.TypePrime, property: calculee

Aux premiers abords, je suis surpris par l’exception retournée, je re-regarde l’entité, tout à l’air correct.
Bien évidemment, je relance mon serveur et refais le même test mais rien n’y fait l’exception est toujours là !

Je commence à me dire qu’il y a quelque chose quand même (biensur !).
Je transforme le type de “calculee” en primitif, je me retrouve ainsi :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class TypePrime implements XXX {

/*...*/
private boolean calculee;

/*...*/

public boolean isCalculee() {
return this.calculee;
}

public void setCalculee(boolean calculee) {
this.calculee = calculee;
}
}

Je vais à nouveau sur ma nouvelle page de test, et là surprise ! Ça marche !

Etant tout de même désireux de mieux comprendre, je cherche la raison et je retourne voir la spéc. des JavaBeans.

Chapitre 8.3.2, on lit :

In addition, for boolean properties, we allow a getter method to match the pattern:

public boolean is‹PropertyName›();

This “is‹PropertyName›” method may be provided instead of a “get‹PropertyName›” method, or it may be provided in addition to a “get‹PropertyName›” method.

In either case, if the “is‹PropertyName›” method is present for a boolean property then we will use the “is‹PropertyName›” method to read the property value.

En résumé, le getter “isXXX()” est pris en compte que pour le type primitif boolean et non son wrapper.

Enfin pour finir, si on aurait pas voulu changer le type de son attribut, il aurait fallu créer la méthode

1
2
3

public Boolean getCalculee() {
return this.calculee;
}

Ça fonctionne également !

Je suis allé vérifié dans le bouquin de la SCJP et c’est bien écrit également, chapitre 1, paragraphe “JavaBeans Standards” => J’arrête l’article !

Angular.js et Spring Security

Hugo Cordier — Mon, 22 Oct 2012 19:55:52 +0000

Il y a déjà quelques temps, Olivier Croisier nous initiait à Angular.js via une application Spring MVC. Question dans les commentaires : comment sécuriser ce type d’application ?

Spring Security

En général, j’essaie de ne pas réinventer la roue, surtout quand il s’agit de sécurité. Ici, puisque l’application se base sur Spring, Spring-Security me semble la solution la plus indiquée.

J’ai commencé par configurer mon serveur grâce à la méthode RTHM (Read The Holy Manual). Spring stocke un id de session chez le client et l’état sur le serveur (il faut bien faire quelques concessions, todo.ng n’est plus complètement stateless).

Notre application s’attend à recevoir les informations de connexion via un formulaire. Après vérification de la validité du login/mdp, il renvoie au client une redirection vers la page correspondante (failed ou success). C’est ce mécanisme de redirect qu’il va falloir remplacer, et cela se fait très facilement.

J’ai forké (du verbe forker : je fork, tu forks, il fork,..) l’application d’Olivier pour lui ajouter ce nouveau comportement. Je vous passe les détails de configuration de Spring-security, le manuel est bien plus bavard et précis que moi. Intéressons-nous plutôt à ce morceau de context-security.xml :

L’entryPoint définit l’objet qui est appelé si l’on veut accéder à une ressource interdite. Et comme leurs noms l’indiquent, chaque handler traite une situation du processus : le login réussit, le mauvais login et le logout.

Le paramètre auto-config gère le reste : les URLs à appeller pour se connecter sont celles par défaut :

S’authentifier : POST(‘j_spring_security_check’, username/password, content-type=x-www-form-urlencoded)

Se déconnecter : GET(j_spring_security_logout)

J’ai donc définit mes propres handlers, qui renvoient un statut 200 en cas de connexion réussie, 403 si le login/mdp est invalide et 401 si on essaye d’accéder à une ressource interdite.

Il ne reste plus qu’à sécuriser les URLs, et plus finement, les controllers : @PreAuthorize devrait vous y aider.

Angular.js

Je vous laisse découvrir ici le controller Angular.js qui gère ces appels. Rien de bien sorcier.

Test

Pour tester le bon fonctionnement de l’application, on ne va autoriser la création d’entrées Todo qu’aux personnes connectées. J’ai donc ajouté une annotation @PreAuthorize au dessus du handler correspondant, dans TodoController (il faut penser à activer les annotations security et ajouter les modules AOP de Spring).

L’identifiant est ‘rod’, mot de passe ‘koala’ (comme dans la doc de Spring)

Dorénavent, seul les personnes connectées peuvent créer des Todo.

Source : Un monsieur en parlait avant moi, et en anglais ici (http://gal-levinsky.blogspot.fr/2011/08/spring-security-3-ajax-login.html)

[1] Oui, le mot de passe est envoyé en clair au serveur, mais cela suffit pour le type de service que je développe.

Liferay 6.0 – Corriger la recherche de contenu Web par type

Florian Lemarchand — Sun, 30 Sep 2012 06:58:46 +0000

Liferay est un portail d’entreprise open-source conçu en Java. Il comporte un grand nombre de fonctionnalités de publication, de gestion de contenu, de documents ainsi que divers composants collaboratifs. Liferay propose également de créer ses propres composants et de redéfinir le comportement et la structure du portail et de ses composants.

En tant que gestionnaire de contenu Web, Liferay offre la possibilité de créer et de rechercher du contenu au sein du portail tout en filtrant les différents contenus en fonction de leur type, que ce soit une page wiki, de blog, une actualité …

La procédure à suivre pour cela est très simple : il suffit de préciser le type d’un contenu créé comme présenté ci-dessous en utilisant la portlet “Web Content Display” :

La portlet de recherche doit ensuite être configurée de la manière suivante afin de pouvoir rechercher du contenu à partir du type de contenu souhaité :

Cependant, je me suis aperçu lors d’une mission qu’une erreur s’était glissée dans la portlet de recherche. En effet, non seulement la recherche retourne les documents de la catégorie attendue mais aussi tous les autres documents du portail. Cette fonctionnalité n’a donc aucunement le comportement attendu.

Cela étant, cette erreur ne concerne que les versions antérieures à la 6.1.0, version où cette erreur a été corrigée.

Pourquoi ?

Regardons comment une recherche de contenu est effectuée. Lors d’une recherche, les mots-clés saisis, “Keywords” et la catégorie des documents recherchés, ici appelée type, sont récupérés sur la page Search.jsp de la portlet “Journal Content Search”. Ces paramètres sont ensuite transmis dans un Contexte de Recherche (SearchContext) et utilisés par un Indexer qui va se charger de retourner les résultats.

1
2
3
4
5
6

Indexer indexer = IndexerRegistryUtil.getIndexer(JournalArticle.class);
SearchContext searchContext = SearchContextFactory.getInstance(request);
searchContext.setAttribute("type", type);
searchContext.setGroupIds(null);
searchContext.setKeywords(keywords);
Hits results = indexer.search(searchContext);

Or, cette recherche ne produit pas le résultat attendu. En effet, bien que le type soit précisé en tant qu’attribut, celui-ci n’est pas récupéré et utilisé par l’Indexer (ici, JournalIndexer).

La logique voudrait que l’on surcharge la fonction Search de la classe JournalIndexer, mais cette manipulation impliquant l’utilisation d’un plugin EXT, nous allons utiliser une méthode alternative.

Pourquoi ne pas utiliser de plugin EXT ?

A la vue des implications qu’engendre l’utilisation d’un plugin EXT, nous allons plutôt utiliser un plugin HOOK. Pour plus d’informations, je vous invite à lire l’article wiki à ce sujet.

Il suffit de créer un plugin HOOK, de modifier la page search.jsp de la portlet Journal Content Search et d’ajouter une condition booléenne (qui doit donc répondre par “true”) au SearchContext :

1
2
3
4
5
6
7
8
9
10
11
12
13

Indexer indexer = IndexerRegistryUtil.getIndexer(JournalArticle.class);
SearchContext searchContext = SearchContextFactory.getInstance(request);
searchContext.setAttribute("type", type);

if(!type.isEmpty()){
BooleanClause clause = BooleanClauseFactoryUtil.create("type", type, "MUST");
BooleanClause[] clauses ={clause};
searchContext.setBooleanClauses(clauses);
}

searchContext.setGroupIds(null);
searchContext.setKeywords(keywords);
Hits results = indexer.search(searchContext);

Ainsi, nous allons récupérer les informations des documents de la catégorie souhaitée uniquement, en incluant, si besoin est, une condition supplémentaire à la recherche.

Foundation 3 et Twitter Bootstrap 2

Victor Leroy — Wed, 26 Sep 2012 14:19:29 +0000

Introduction

Si vous êtes ici, c’est que le web, vous connaissez. Vous faites du développement web toute la journée, mais le jour où vous voulez créer votre propre site, un gros problème se pose. Le site fonctionne parfaitement bien, mais il est moche. En plus, vous avez passé des journées à en arriver là. La frustration vous guette. Et pourtant, il va falloir vous y faire, vous n’êtes pas graphiste et vos goûts personnels sont plutôt discutables.

Pas de panique ! Comme toujours (ou presque), des outils sont là pour vous aider. Mais parmi eux, lequel choisir ? Je vais vous parler ici de deux d’entre eux, Foundation et le désormais fameux Twitter Bootstrap.

CSS preprocessor

Ces deux outils reposent en partie sur des framework CSS : LESS pour Twitter Boostrap et SASS pour Foundation. Je ne vais pas trop m’étendre sur cette partie, les deux outils sont assez similaires. Si vous ne souhaitez pas modifier les styles fournis, ne cherchez pas trop longtemps lequel vous correspond le mieux. Cependant, SASS semble être un peu plus complet et surtout compatible avec Compass. Si vous souhaitez plus d’informations, vous pouvez aller lire cet article comparant LESS et SASS.

Grille et Responsive design

La grille

Foundation et Twitter Bootstrap disposent tous deux d’un système de grille pour faciliter le placement des éléments sur la page. Ces grilles sont découpées en 12 colonnes par défaut mais dans chacun des frameworks, cela est configurable. Cette grille s’ajuste à la taille de l’écran (du navigateur), ce qui est indispensable si l’on souhaite faire du « responsive-design ».

Au niveau du code, voilà à quoi ça ressemble :

Foundation

1
2
3
4
5
6
7
8

<div class="row">
<div class="four columns">
Sidebar...
</div>
<div class="eight columns">
Main content...
</div>
</div>

Twitter Bootstrap

1
2
3
4
5
6
7
8

<div class="row-fluid">
<div class="span4">
Sidebar ...
</div>
<div class="span8">
Main content...
</div>
</div>

Les syntaxes sont plutôt proches mais celle de Foundation me paraît plus lisible bien que moins concise. De plus, Foundation est beaucoup plus souple sur le « Source Ordering ». C’est à dire qu’il est possible d’ordonner son code de manière différente par rapport à l’affichage voulu (ou l’inverse).

Par exemple :

1
2
3
4
5
6
7
8

<div class="row">
<div class="two columns push-ten">
cellule 2
</div>
<div class="ten columns pull-two">
cellule 1
</div>
</div>

S’affichera :

Responsive Web Design

Qu’est-ce que c’est ?

La notion de Responsive Web Design regroupe différents principes et technologies mais il indique globalement qu’un site est conçu pour s’adapter aux différentes tailles d’écran et aux différents terminaux permettant d’afficher le site (navigateur, tablette, mobile, télé connectée, …). Ainsi, les mobinautes pourront avoir une expérience adaptée à leur terminal sans dégradation et sans devoir utiliser les fonctionnalité de zoom (ou un autre type de redimensionnement). Ils pourront consulter la même information, mais organisée différemment selon le type de terminal utilisé.

Wikipedia

Pour nous aider, Foundation propose la gestion d’une deuxième grille en plus de celle à 12 colonnes. Cette grille est orientée mobile, comprendre petits écrans, et est composée de 4 colonnes (par défaut). Elle permet de conserver une disposition correcte sur des écrans à largeur réduite.

1
2
3
4
5
6
7
8
9
10

<div class="row display">
<div class="three mobile-one columns">
3 colonnes de largeur sur écran large (sur les 12 colonnes)
1 colonne de largeur sur écran réduit (sur les 4 colonnes)
</div>
<div class="nine mobile-three columns">
9 colonnes de largeur sur écran large (sur les 12 colonnes)
3 colonnes de largeur sur écran réduit (sur les 4 colonnes)
</div>
</div>

Par défaut, les éléments se seraient retrouvés les uns en dessous des autres, ce qui peut être un comportement déjà satisfaisant.

Avec Twitter Bootstrap, le responsive design est aussi au rendez-vous. Lorsque la largeur de la fenêtre du navigateur/terminal change, la largeur des colonnes change et les éléments s’empilent si l’ écran n’est plus assez large.

Les deux frameworks donnent aussi la possibilité d’afficher ou cacher certains éléments selon la largeur du terminal utilisé, en partie à base de media queries. Foundation propose aussi la détection des écrans tactiles et des modes paysages et portraits.

Pour ma part, je donnerais donc un point à Foundation pour la gestion de la deuxième grille.

Typographie

Au niveau de la typographie (h1, h2, p, ul …), les deux frameworks fonctionnent à peu près de la même manière. Les tailles des caractères et des hauteurs de lignes sont prédéfinies mais peuvent être entièrement personnalisées, soit en utilisant le configurateur en ligne, soit en modifiant après coup le CSS via des variables globales LESS ou SASS. Match nul sur ce point.

Éléments graphiques et Javascript

Vous trouverez un bon nombre d’éléments HTML déjà stylisés en utilisant ces frameworks. Plus besoin de passer des heures sur les styles de vos boutons, formulaires, tableaux… et la liste est longue. Mais ça ne s’arrête pas là. Tous les éléments courants en web sont présents. Tool-tips, breadcrumbs, onglets, fenêtres modales, menus déroulants, accordéons, carrousels…

Là, Twitter Bootstrap semble gagner la manche par le nombre de composants disponibles. Cependant vous trouverez peut-être dans l’un ou l’autre, LA fonctionnalité que vous recherchiez.

Conclusion

Les deux frameworks présentés ne sont pas si différents l’un de l’autre. Alors, lequel choisir ? Déjà, cela dépendra de vos obligations, professionnelles ou personnelles. Foundation n’étant pas compatible IE7, ça peut refroidir plus d’un DSI. Cependant, cela explique quelques unes des différences au niveau du responsive design. Ensuite, la communauté autour de Twitter Bootstrap semble plus grande (je n’ai pas dit plus active). Environ 35000 « stars » et 8000 « forks » sur github pour Twitter et presque 6000 « stars » et 800 « forks » pour Foundation (je ne suis pas sûr que la métrique soit la meilleure). Ce qui peut être un avantage en environnement professionnel.

Au niveau des licences, Twitter Bootstrap est sous licence Apache 2 et Foundation sous licence MIT. Ce qui ne devrait pas changer grand chose pour vous.

J’entends déjà les « Ouais mais moi j’veux pas avoir le même site que les autres ». Bon déjà, comme vu dans l’introduction, quand on a pas bon goût, on évite de se plaindre. Ensuite, il existe des sites pour vous aider à choisir la palette de couleurs qu’il vous faut, et ainsi personnaliser le plus possible votre site. Vous en trouverez une liste ici.

Vous voilà maintenant au courant. Fini les : « je sais que c’est moche mais j’ai fait ça vite fait ! ».

Guide pratique sur l’encodage à l’usage des développeurs JavaEE

mgrenonville — Thu, 20 Sep 2012 14:55:04 +0000

Au cours de mes différentes missions, j’ai pu être confronté plusieurs fois à des problèmes d’encodage. À chaque fois (ou presque), le problème était situé entre la chaise et le clavier. Et une fois, il s’agissait d’IE7. Cette fois exceptée, des règles simples permettent de les éviter. Et en comprenant les erreurs fréquentes, on trouve plus facilement la solution. Ces erreurs trouvent leurs origines dans la manière dont sont encodés les caractères.

Deux approches

Coder le caractère

L’origine des encodages vient des Téléscripteurs (1866 !), dont le but était de transmettre des informations via des signaux électriques. Il a donc fallu un code. Un des premiers standardisés est le Code Baudot, suivi de très près par le code ASCII. Pas de chance pour les non-anglophones, il ne permet pas de coder les caractères accentués. L’ASCII est composé de 128 caractères, dont 33 de contrôles. Ces caractères de contrôles sont très fortement liés à la technologie de l’époque : mon petit préféré ? le caractère BEL. Si vous avez déjà tapé à la machine à écrire, il doit vous être familier, c’est annonciateur de fin de ligne

Mais pourquoi seulement 128 caractères, sachant que c’est 2^7 ? Il aurait été plus intelligent de faire un octet complet ! Sauf qu’à l’origine, le dernier bit de l’octet est utilisé en bit de parité, pour détecter les erreurs de transmissions. Mais les non-anglophones finissent par avoir raison de celui-ci et développe rapidement des encodings qui incluent les caractères de la localisation (la devise, les accents, etc.). Sauf qu’avec 8 bits, les possibilités de représentation sont limitées. Ainsi, il existe un ISO-8859 par alphabet (Grec, Cyrillique, Latin, …). Bien sur, ils ne sont pas compatibles entre eux, puisque tous les caractères dont le code est supérieur à 128 sont des caractères locaux. Les échanges de mails sont rapidement devenus une plaie.

Sans compter qu’on ne peut pas représenter sur 256 valeurs l’intégralité des logogrammes présents dans les langues orientales notamment. C’est pourquoi des gens ont commencé à travailler sur Unicode.

Coder la représentation d’un caractère…

Unicode est une couche d’abstraction entre le caractère et son encodage. Pour bien comprendre, il faut savoir qu’un caractère Unicode porte un nom. La lettre “a” s’appelle “LATIN SMALL LETTER A”. La lettre “À” s’appelle “LATIN CAPITAL LETTER A WITH ACUTE”, etc. Ce nom est normé, et ne dépend absolument pas de la forme de la lettre, de la police, ou de sa représentation. On peut penser en caractère d’imprimerie. Par exemple, si vous avez déjà utilisé LaTeX (ou un éditeur de PAO type inDesign), vous avez sûrement noté les ligatures sur ff et fi : il existe un caractère Unicode (et bien un seul caractère, essayez de le sélectionner : ﬁ et ﬀ) pour chacune d’entre-elle.

Chaque caractère Unicode est ensuite numéroté : “LATIN SMALL LETTER A” est U+0061. Ce numéro est un “code-point”. Le U+ définit qu’il s’agit d’Unicode, les chiffres qui suivent sont en hexadécimal. Il existe sous les différents OS un utilitaire pour trouver les valeurs unicode de chaque caractère, et une multitude de sites internet.
Une chaîne Unicode n’est rien d’autre qu’une suite de codes-points Unicode. UTF-8, UTF-16, UCS-2, … sont des encodages. Ils servent à coder les codes-points.

Intéressons-nous au célèbre UTF-8. C’est un format dont le but initial était de faciliter la migration à Unicode de documents ASCII vers UTF-8. L’astuce se situe dans l’attribution des mêmes octets entre l’UTF-8 et l’ASCII : Un “A” encodé en ASCII s’écrit 0×61, et en UTF-8, 0×61 (mais en Unicode, le “A” s’écrira U+0061 ou “LATIN SMALL LETTER A”, pas autrement !)
Jusqu’ici, tout est simple, sauf que Unicode définit dans la dernière version 110 182 codes-points. Nous sommes donc très loin des 256 valeurs possibles dans un octet. Voyons comment UTF-8 s’en sort.

… et encoder un code-point

Dans le tableau ci-dessous, on peut voir la manière dont sont stockées les chaînes Unicode en UTF-8. (NB : le tableau complet est disponible sur wikipedia)

Bits	Last code point	Byte 1	Byte 2	Byte 3
7	U+007F	0xxxxxxx
11	U+07FF	110xxxxx	10xxxxxx
16	U+FFFF	1110xxxx	10xxxxxx	10xxxxxx

source et version complète

Pour encoder le caractère “ũ” U+0169 en UTF-8,

D’après le tableau, le code-point (0×169) est compris entre 0x007F et 0x07FF, il faudra donc 2 octets pour l’encoder.
0×169 est égal en binaire à 101101001b.
Les bits du code-point servent à remplacer les x du tableau : 110xxxxx 10xxxxxx devient : 1100101 10101001

Une erreur courante est de confondre Unicode et UTF-8. UTF-8 est un encodage permettant de représenter Unicode, pas Unicode.

Et dans la pratique ?

Vers de l’Unicode

Prenons la chaîne suivante “à”. Il est impossible de l’encoder en ASCII, puisque “à” ne fait pas partie de cet encodage. En revanche, en ISO8859-1, c’est tout à fait possible :

1 2	byte[] bytes = new String("à").getBytes("iso8859-1"); for (byte aByte : bytes) System.out.format("%X",aByte);

On obtient : 0xE0, soit 11100000, ou 224 en décimal. Qu’en est-il de l’UTF-8 ? On obtient 0xC3 0xA0. Ainsi, UTF-8 utilise bien 2 octets pour coder un caractère, là où ISO8859-1 n’en utilisait qu’un.

Simulons une erreur courante : un caractère encodé en ISO-8859-1 est lu en tant que chaîne UTF-8.

1
2
3

byte[] bytes = new byte[]{(byte) 0xE0};
String test = new String(bytes, "utf-8");
System.out.println(test);

Un caractère qui doit vous être familier s’affiche : � (soit : ‘REPLACEMENT CHARACTER’ ou U+FFFD). Ce caractère sert à représenter un caractère non représentable dans l’encodage choisi (UTF-8 ou UTF-16). On a donc connaissance des erreurs de décodage. On peut donc “sans risque” décoder un flux ISO-8859 en UTF-8 : UTF-8 saura repérer certains caractères en erreur. En revanche, le remplacement se fera avec le même caractère pour toutes les erreurs : il y a perte d’information (mais elle est connue !)

Depuis l’Unicode

Toujours avec notre chaîne “à”, il est possible de l’encoder via Unicode en UTF-8. On obtient alors les 2 octets 0xC3 et 0xA0. Simulons une autre erreur courante : le caractère encodé en UTF-8 et lu en tant que chaîne ISO-8859-1 :

1
2
3

byte[] bytes = new byte[]{(byte) 0xC3, (byte) 0xA0};
String test = new String(bytes, "iso8859-1");
System.out.println(test);

Cette fois, on obtient : “Ã ” (soit, en Unicode : “LATIN CAPITAL LETTER A WITH TILDE (U+00C3)” “NO-BREAK SPACE (U+00A0)”). UTF-8 utilisant 2 octets, il est normal que ISO-8859-1 voit 2 caractères. Cependant ici, aucun moyen de détecter une erreur, et pourtant, celle-ci doit aussi vous être familière ! Et le problème ici est qu’il n’y a aucun moyen de détecter l’erreur ! Pas de perte d’information, juste une mauvaise interprétation, sans remplacement.

S’il vous est déjà arrivé de manipuler des fichiers ouverts par des outils mal configurés (ISO-8859-1 vs UTF-8), vous avez surement remarqué qu’un fichier ISO-8859-1 ouvert en UTF-8 et écrasé n’est plus récupérable (du fait du caractère de remplacement U+FFFD). En revanche, ouvrir un fichier UTF-8 en ISO-8859-1, l’éditer avec des caractères ASCII et l’enregistrer ne l’affecte pas. Voici l’explication !

Et dans la vie de tous les jours ?

Un flux d’octet n’a aucun sens sans Charset

Décoder un flux d’octet est une opération courante, à chaque requête, l’implémentation de HttpServletRequest présente dans le conteneur web décode les informations associées à la requête : ici dans tomcat

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

/**
* Parse request parameters.
*/
protected void parseRequestParameters() {

requestParametersParsed = true;

Parameters parameters = coyoteRequest.getParameters();

String enc = coyoteRequest.getCharacterEncoding();
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) {
parameters.setEncoding(enc);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(enc);
}
} else {
parameters.setEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}

parameters.handleQueryParameters();

if (usingInputStream || usingReader)
return;

if (!getMethod().equalsIgnoreCase("POST"))
return;

String contentType = getContentType();
if (contentType == null)
contentType = "";
int semicolon = contentType.indexOf(';');
if (semicolon >= 0) {
contentType = contentType.substring(0, semicolon).trim();
} else {
contentType = contentType.trim();
}
if (!("application/x-www-form-urlencoded".equals(contentType)))
return;

int len = getContentLength();

if (len > 0) {
try {
byte[] formData = null;
if (len < CACHED_POST_LEN) {
if (postData == null)
postData = new byte[CACHED_POST_LEN];
formData = postData;
} else {
formData = new byte[len];
}
int actualLen = readPostBody(formData, len);
if (actualLen == len) {
parameters.processParameters(formData, 0, len);
}
} catch (Throwable t) {
; // Ignore
}
}

}

Voyons comment le régler correctement dans une solution Spring MVC déployé dans un tomcat.

Client

Le client (ici le navigateur WEB) reçoit une réponse HTTP depuis un serveur (peu importe la requête d’origine). Il existe plusieurs moyens de jouer sur l’encoding.
La RFC 2616 (HTTP/1.1) est claire de ce point de vue : le Header HTTP Content-Type est dédié à cet effet.
En Spring MVC, il est facile de mettre ce header dans toutes les pages générées, directement dans le ViewResolver :

1
2
3

id="freemarkerViewResolver" class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver">
name="contentType" value="text/html; charset=UTF-8" />
>

Il est bien entendu possible de surcharger cette valeur directement dans la View. En JSP, il suffit de mettre dans la page :

1	<%@page contentType="text/html; charset=UTF-8" %>

On peut aussi mettre ce Header directement dans Apache/nginx. Il faudra aussi penser à régler les outils pour générer de l’UTF-8 (dans Freemarker, la propriété url_escaping_charset et output_encoding). Malheureusement, il se peut que nous n’ayons pas accès à cette possibilité. Que faire alors ?
Dans la page HTML, il est possible de définir un meta dans l’élément head :

1
2
3

Quelle bizarrerie ! Commencer à lire un flux sans définir son encoding et attendre quelques octets avant de le connaître… Heureusement que la plupart des encodings utilisent les mêmes octets que dans l’ASCII.

Ne pas suivre ces recommandations vous expose à toutes sortes de choses incluant des incendies, des pluies de bananes, des tas de m**** – oui, il y a un caractère pour tout – et de la p****graphie (SFW) ! Plus sérieusement, les navigateurs essayeront de deviner à partir d’analyses statistiques le couple langue/encodage le plus probable. Chose qui fonctionne bien, jusqu’au jour où l’utilisateur écrit un texte qui sort du profil statistique, ce qui est fréquent, en particulier s’il poste du code.

Une fois l’encodage détecté (avec succès ou pas), le navigateur enverra éventuellement des données au serveur (via des requêtes GET, POST ou PUT). L’encoding utilisé par le navigateur pour envoyer le flux au serveur est celui de la page. D’où l’importance de maitriser celui-ci !

Serveur

Ainsi, nous savons que le navigateur nous poste le flux en, au hasard, UTF-8. Parfait. La RFC 2616 définit dans le paragraphe 3.7.1 que par défaut, si aucun encoding n’est spécifié, il faut lire les données en ISO-8859-1.

De fait, dans la spécification de JSP, le point SRV.3.9 définit que l’encoding utilisé par défaut pour le décodage des paramètres (GET et POST) est ISO 8859-1 (Plus d’informations ici sur le pourquoi du comment)

Cependant, lorsque les pages sont affichées en UTF-8, le navigateur enverra les données en UTF-8. Pour forcer le conteneur de servlet à lire les paramètres en UTF-8, une solution à base de Filter est disponible dans Spring : CharacterEncodingFilter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CharacterEncodingFilter>

org.springframework.web.filter.CharacterEncodingFilter>

encoding>

UTF-8>
>

forceEncoding>

true>
>
>

CharacterEncodingFilter>

webapp>
>

Ainsi, à chaque requête, le filtre s’applique et force (ou pas) l’encodage pour la lecture des paramètres. Lorsque le paramètre forceEncoding est vrai, le filtre va aussi forcer l’encoding sur la réponse.
Attention, si vous avez bien lu le code de CoyoteRequest, à la première ligne de parseRequestParameters(), il y a un : requestParametersParsed = true. Je vous le donne en mille, l’interprétation des paramètres n’est faite qu’une seule fois. Le filtre qui force le Charset doit donc être appliqué avant la première lecture de paramètre !

Enfin, une dernière chose peut-être faite afin d’autoriser les URI en UTF-8 (comme wikipedia) : ajouter URIEncoding=”UTF-8″ sur l’élément dans le server.xml de tomcat.

Une fois toutes ces manipulations effectuées, vous pouvez presque dire adieu aux problèmes d’encoding. Pourquoi presque ? Parce qu’il faut être sur que tous les flux que vous générez sont bien dans l’encoding que vous avez choisi. Attention tout particulièrement aux MessagesBundle dans Spring. La spécification des fichiers de properties indique qu’ils doivent être en ISO-8859-1. Et Eclipse suit cette norme. La solution pour stocker des caractères au delà des 256 possibles dans ISO-8859-1 ? Les mettre en UTF-8 et prier le dieu Unicode pour que personne n’écrase le fichier avec une version ISO-8859-1, ou alors utiliser native2ascii (en standard dans le JDK) pour transformer ses chaînes avant de les enregistrer dans le fichier (un plugin Eclipse existe pour le faire automatiquement ). Vous voilà prévenus !

Pour aller plus loin

Je ne saurai que trop vous conseiller la lecture des articles suivants :

Merci à Nicolas Maupu pour la photo

Article écrit sous Creative Commons 3.0 BY-SA.

Meilleure gestion de logs sur Android

Damien V. — Wed, 12 Sep 2012 17:06:11 +0000

Mise en situation

Android dispose d’une gestion de logs assez intéressante. On y retrouve la notion de niveau de logs, et la possibilité de poser un tag sur chaque ligne. Pour les visualiser, on passe par le plugin ADT et sa vue LogCat.

Tout cela c’est bien beau… Mais ce système impose d’avoir accès au smartphone (ou à la tablette) pour consulter les logs. Or, dans ma mission actuelle, le projet est envoyé en pilote à différents endroits en France. Il n’est donc pas pensable de se déplacer pour consulter ces informations, et le personnel présent a autre chose à faire que de taper des lignes de commandes ou de lancer Eclipse.

Alors quoi ? Comment konfai ?

J’ai donc cherché des solutions de logs en me basant sur ce qui existe déjà pour Java/JEE. Et il y a des projets portant les principaux frameworks de logs sur ces terminaux. Parfait !

Parmis d’autre, on retrouve donc les librairies suivantes :

Après quelques tests, je me suis rapidement orienté vers Logback-Android pour plusieurs raisons :

je l’utilise déjà au quotidien ;
il intègre une large panoplie d’appender (dont FileRollingAppender, DBAppender, SocketAppender) ;
il est configurable de plusieurs façons (AndroidManifest, logback.xml, programmatiquement) ;
et surtout, Logback, c’est la vie.

Ci-dessous mon fichier logback.xml pour l’exemple. On y retrouve bien la syntaxe usuelle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

version="1.0" encoding="UTF-8"?>
>
name="FILE" class="ch.qos.logback.core.FileAppender">
>/sdcard/logs/epod.log>
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

>/sdcard/logs/epod.%d{yyyy-MM-dd}.log>

>30>
>
class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36}:%line - %msg%n>
>
>

level="DEBUG">

ref="FILE" />

>
>

Et les logs on les récupère comment ?

La solution la plus simple serait de configurer un SocketAppender et d’envoyer le tout sur un serveur dédié à cette tâche. Mais cela nécessite que le terminal soit toujours relié au réseau, ce qui est loin d’être évident avec des appareils mobiles.

Pour mon projet, les appareils en question sont des tablettes qui sont toujours reliées à un réseau interne. Elles communiquent avec le SI grâce à Soja. Pour simplifier les choses, on a donc opté pour une solution nous permettant de récupérer les logs sur la tablette, uniquement lorsque l’on en a besoin.

La tablette souscrit à deux topics fixés : /logs/list et /logs/download ;
on envoie un message sur le topic /logs/list contenant le nom d’un autre topic sur lequel envoyer la réponse ;
la tablette renvoie la liste des fichiers de logs disponibles ;
on envoie un second message sur le topic /logs/download contenant le nom d’un topic de réponse et le fichier à envoyer.

Communication STOMP pour récupérer les logs

Conclusion

Il existe donc des librairies de logs intéressantes pour Android. Pour les puristes, on peut très bien intégrer une de ces solutions avec un appender qui renvoie le tout sur LogCat et ainsi ne pas changer leurs habitudes