In Fine, en tant que partenaire de l’évènement majeur qu’est Devoxx France, a le plaisir de mettre à disposition une application pour Devoxx France sur Android. Cette première version permet :

• De mettre en favoris vos sessions préférées
• De consulter le planning des sessions, et le détail des speakers
• De voir ce qui se passe sur Twitter avec le tag devoxxfr
• D’avoir accès au plan des 2 étages de l’hôtel où se déroulera la conférence
• Et d’autres fonctionnalités…

Cette application fonctionne parfaitement sur téléphone , mais n’est pas encore totalement adaptée pour les tablettes. Dans les semaines qui viennent, nous allons continuer à mettre à jour l’application pour qu’elle soit la plus simple à utiliser possible. Voici une prévision des futures évolutions :

• Complète adaptation de l’ergonomie de l’application aux tablettes
• Ajout de la recherche sur les speakers. Actuellement elle ne fonctionne que sur les sessions
• Quand on clique sur une salle, afficher la carte de l’étage correspondant
• Pouvoir mettre en favori des speakers
• Et bien d’autres choses qui dépendront des retours que nous aurons

Nous sommes très fiers de mettre à disposition cette application. Elle sera mise en open source au moment de la conférence Devoxx France, certainement en licence Apache 2.
Si vous rencontrez des problèmes ou avez des suggestions, écrivez un commentaire ici, ou envoyer un mail au compte indiqué sur la fiche du Google Play Store.

Dans la suite de l’article, nous allons approfondir l’aspect technique de l’application. Si au contraire vous souhaitez directement aller télécharger l’application, alors il faut aller ici : Play Store

Architecture technique

Comme le montre le schéma ci-dessus, nous n’avons pas directement connecté l’application Android avec les API RESTful fournies par le site Devoxx. En effet les temps de réponse sont très variables, certains service ont déjà mis plus de 5 minutes à répondre. D’autre part, certains service renvoient des données en double ou incomplètes.
Le serveur intérmédiaire permet donc de mieux maîtriser les données. Grâce à Play et à Mongo DB, les temps de réponse sont excellents et la charge que peut encaisser le serveur est bien au dessus de ce que nous atteindrons. Un test JMeter a mesuré que le serveur pouvait encaisser 300 requêtes par secondes. La plupart des requêtes répondent en moins de 0.1 seconde. Nous estimons que le serveur aurait à supporter, au maximum de son activité, 25 requêtes par minute

The post L’application Devoxx France d’In Fine est disponible sur le Google Play Store first appeared on In Fine - Le Blog.

Cet article est destiné à ceux qui ont la ‘chance’ d’avoir Tomcat 6 comme serveur pour leurs applications et qui doivent paramétrer le pool de connexions par JNDI.

Voici un petit article issu d’une demande d’un client.

Le client : C’est bien la configuration par JNDI, ça serait mieux si on ne voyait pas le mot de passe en clair …

Moi: No problem, everything is possible (enfin je crois) …

Effectivement c’est possible. D’après la documentation, il suffit d’implémenter une classe de type ‘factory’ pour instancier les connexions avec la base de données.

Dans cet article, vous verrez comment crypter facilement un mot de passe ou autre mais aussi comment remplacer le pool de connexion DBCP  par le pool de connexion de Tomcat 7 (plus performant à  mon goût).

Tout ceci se fait en 3 étapes :

• Codage d’une classe ‘Factory’
• Configuration de la ressource JNDI
• Copier les jar dans le répertoire lib de Tomcat

Le processus de cryptage ne sera pas détaillé ici.
Pour plus d’information, vous avez une classe “EncryptHelper” dans les sources (voir à la fin).

1° La classe Factory

Ici j’utilise le pool de connexion de Tomcat 7 :

public class Tomcat7EncryptedFactory extends org.apache.tomcat.jdbc.pool.DataSourceFactory implements SecuredFactory{

	@SuppressWarnings("rawtypes")
	@Override
	public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception {
		Object o = super.getObjectInstance(obj, name, nameCtx, environment);
		if (o != null && o instanceof org.apache.tomcat.jdbc.pool.DataSource) {
			org.apache.tomcat.jdbc.pool.DataSource ds = (org.apache.tomcat.jdbc.pool.DataSource) o;
			// recuperation du login et mot de passe cryptes
			String cryptedUsername = ds.getUsername();
			String cryptedPassword = ds.getDbProperties().getProperty("password");
			// on decrypte le password
			if (cryptedPassword != null && cryptedPassword.length() > 0) {
				String pwd = EncryptHelper.decryptData(secretKeyPassword, cryptedPassword);
				ds.setPassword(pwd);
			}
			// on decrypte le login
			if (cryptedUsername != null && cryptedUsername.length() > 0) {
				String username = EncryptHelper.decryptData(secretKeyUser, cryptedUsername);
				ds.setUsername(username);
			}
			// on set la taille initiale avec le minimum idle
			// on doit laisser le initialSize a 0 car il ne faut pas cree de connexion tout de suite car on a les identifiants cryptes.
			int minIdleSize = ds.getMinIdle();
			ds.setInitialSize(minIdleSize);
			ds.setConnectionProperties(ds.getConnectionProperties());

			// on ferme le pool deja parametre
			ds.close();
			// on recree le pool avec les nouveaux parametres
			ds.createPool();
			System.out.println("Initialisation de la datasource JNDI : OK");
			return ds;
		} else {
			System.out.println("Initialisation de la datasource JNDI : KO");
			return null;
		}
	}
}

Juste que la rien de difficile ^_^

2° Configuration JNDI

Extrait du fichier de configuration des ressources de Tomcat 6 (conf/context.xml)

    auth="Container" type="javax.sql.DataSource"
    factory="fr.cnvt.tomcat.Tomcat7EncryptedFactory"
    username="sD20tsCeFQPP3HuQV17yXw=="
    password="LoPCUiDWD47S6wIOTZWvBX7X9XTLt2vS9Sv52csoEGo="
    driverClassName="my.driver.class"
    url="my.jdbc.url"
    initialSize="0" maxActive="20" minIdle="5" maxIdle="10"
    validationQuery="SELECT 1 FROM Dual" validationQueryTimeout="300"
    maxWait="30000"
    removeAbandoned="true" removeAbandonedTimeout="600" logAbandoned="true"
    timeBetweenEvictionRunsMillis="20000"
    testWhileIdle="true"
    connectionProperties="CHARSET=utf8;" />

Comme vous pouvez le voir, le login (username) et le mot de passe (password) sont cryptés.

Vous pouvez avoir le même login et mot de passe (c’est bizarre comme c’est fréquent…) , les 2 chaines cryptés seront différentes (normal j’utilise 2 clés de cryptage différentes ^_^)

3° Librairies dans Tomcat

Dernières étapes, il suffit de copier les fichiers tomcat-datasource-factory-1.0.0.jar et tomcat-jdbc-7.0.22.jar(dans le répertoire lib du zip) dans le répertoire “lib” de Tomcat 6.

Voila en 3 copié-collé, vous avez un pool de connexion sans mot de passe en clair ^_^

Pour générer vos propres login et password cryptés, il suffit d’utiliser la classe EncryptHelper comme ceci:

	@Test
	public void generateEncryptedValues(){
		String login = "monsupertest";
		String password = "monsupertestaussi";
		String cryptedLogin = EncryptHelper.encryptData(SecuredFactory.secretKeyUser, login);
		String cryptedPassword = EncryptHelper.encryptData(SecuredFactory.secretKeyPassword, password);
		String decryptedLogin = EncryptHelper.decryptData(SecuredFactory.secretKeyUser, cryptedLogin);
		String decryptedPassword = EncryptHelper.decryptData(SecuredFactory.secretKeyPassword, cryptedPassword);
		assertEquals(login, decryptedLogin);
		assertEquals(password, decryptedPassword);
		System.out.println("Login crypte : " + cryptedLogin);
		System.out.println("Mot de passe crypte : " + cryptedPassword);
	}

Pour les curieux, le fichier zip contient également un pool DBCP et C3P0 qui gèrent aussi le login et mot de passe cryptés. Les clés de cryptages sont dans l’interface SecuredFactory.

Enjoy

Les sources sont disponibles ici

The post Tomcat 6 – JNDI – password crypté et pool de connexion V7 first appeared on In Fine - Le Blog.

Comparatifs de frameworks web à Devoxx 2011

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

The post Devoxx 2011 – Comparatif de performances des frameworks web Java et plus encore … first appeared on In Fine - Le Blog.