samedi 21 février 2009

De l'utilité des certifications

Personnellement, j'ai trois certifications Java:
  • Java programmer sur JDK 1.4,
  • Web component pour J2EE 1.4,
  • Business component pour J2EE 1.4.
Je me pose la question de l'utilité de les mettre à jour.
Drôle de question lorsque l'on se fi à ce que le site veut nous faire croire: passer une certification vous donnera une justification de votre niveau dans une technologie et ne peut être que bénéfique pour valoriser votre CV.

Mes certifications n'ont jamais eu la moindre influence sur mon parcours, pour preuve, juste après les avoir passées, mon patron m'a assigné à des projets Perl et C++. Et aucune chance de basculer vers des projets Java, j'ai essayé...

Et ce n'est pas plus valorisant pour postuler dans une nouvelle société. A chaque entretien, je soulignais soigneusement mes certifications pour montrer à quel point mon niveau était élevé... Mais les employeurs potentiels ne s'intéressaient qu'aux différents projets sur lesquels j'avai travaillé.

Ma démarche concernant les certification était la suivante: une certification pour appréhender une technologie. Je pense que je m'y suis pris à l'envers.La certification devrait permettre d'entériner une expérience professionnelle: un projet J2EE 5 pendant un an, puis la certification.

Sans savoir faire, la connaissance théorique apportée par la préparation d'une certification n'apporte malheureusement pas grand chose. Je me souviens d'un projet servlet/JSP sur lequel j'ai travaillé après avoir passé la certification web component. Heureusement que j'avais le livre qui m'a servit à la préparer, sinon, le projet aurait difficilement aboutit.

Une autre question: l'expérience ne serait elle pas en faire valoir suffisant? Est il réellement besoin de passer un examen pour valider des connaissances aquises pendant la réalisation de projets?

jeudi 19 février 2009

Adobe Flex 3: Training from the Source de Jeff Trapper, Michael Labriola, Matthew Boles, James Talbot

Ce livre est prétexte à la mise en place d'une application d'e-commerce, ce qui permet de faire le tour des différents aspets de Flex.
J'avais une peur concernant ce livre, c'est qu'il soit centré uniquement sur Flex Builder, l'environement de dévelopement d'Adobe. Dans les premières leçons, l'environement est utilisé de manière intensive, mais on arrive rapidement à mettre les mains dans le MXML et l'ActionScript.
Chaque chapitre est centré sur un théme, qui est expliqué en dehors du contexte de l'application d'e-commerce, avec plusieurs exemples simples. Puis, la leçon est appliquée à l'application, pas à pas. Le code disponible sur le CD permet de reprendre une leçon au début ou, suivant sa longueur, au milieu de celle-ci.
Une bonne surprise est que des rudiments de la plateforme AIR font l'objet d'un chapitre.
Seul regret, concernant la partie communication avec le serveur, aprés l'annonce tonitruante en 2007 à Javapolis, de la disponibilité de Flex 3 et de ses formidables possibilités d'intégrations avec Java, que le backend fournit soit basé sur ColdFusion. J'aurais également voulu abordé la communication avec le serveur un peu plus tôt.
Globalement un bon livre, à ranger dans les livres de référence sur le sujet.

mercredi 28 janvier 2009

Java EE 5 2e édition par Antonio Goncalves

Un bon livre d'initiation aux spécifications J2EE. Il couvre les principaux sujets auxquels on pouvait s'attendre. Le bémol vient des trois premiers chapitres qui portent sur la description de l'application sur laquelle est basé l'ouvrage et sur l'environnement de développement.
L'application est le traditionnel magasin d'animaux en ligne. L'auteur précise qu'il utilise cette application parce qu'elle fait parti d'un blue print de Sun et non par commodité. On lui pardonnera donc d'utiliser cet exemple "bateau".
Ce que j'ai également beaucoup apprécié est la description de JAXB comme étant une des pièces maitresse des web service.
Je recommande ce livre à tous ceux qui veulent avoir une overview de la spécification J2EE. Sans permettre de construire une application compléte, cet ouvrage forunit un quick start sur un grand nombre des technologies Java.

mardi 25 novembre 2008

Injection d'une DataSource dans un contexte Spring

Cet article a pour but de décrire comment injecter une datasource dans un contexte Spring existant et surtout de décrire les solutions que j'ai envisagé.

La problématique

Dans le cadre du développement d'une API devant interroger une base puis traiter ces données, les contraintes techniques suivantes sont apparues :
  • une seule classe doit servir de façade pour utiliser l'API,
  • celle-ci doit prendre une DataSource définit par le client,
  • la partie cliente ne doit pas avoir connaissance du contexte Spring de l'API.
Sachant que la partie cliente est dépendante du framework Spring, son utilisation dans ce cas de figure semblait naturel. Ainsi, la partie ORM du framework permet de coder plus rapidement les accès à la base et le fichier de contexte permet de résoudre les problèmes d'injection de dépendance, de transaction et permet d'éviter l'écriture de fabriques.
Les beans d'accès aux données ainsi que les beans gérant les transactions ont besoin d'une DataSource pour pouvoir fonctionner.
Comment faire pour créer le bean d'entrée de la librairie, donc charger le contexte, sans qu'une exception soit lancé par Spring? Comment faire pour que Spring s'occupe de l'injection de la DataSource alors que celle-ci n'est connu qu'au moment d'utiliser la librairie?

Quelques solutions

Injecter manuellement la DataSource

L'idée ici est de créer le bean façade de l'API, d'y injecter les dépendances et d'injecter manuellement la DataSource.
Cette solution oblige le développeur à connaitre le nom des beans dépendants de la DataSource. Toute modification du contexte implique alors d'intervenir dans le code.

Injection de la DataSource par Spring

Cette fois ci, il s'agit de laisser Spring injecter la DataSource dans les beans.

La méthode d'initialisation du bean:

public void init(DriverManagerDataSource driverDataSource) throws EngineException {
// premièrement, création d'un contexte parent
ConfigurableApplicationContext genericContext = new GenericApplicationContext();
DefaultListableBeanFactory beanFactory = (DefaultListableBeanFactory) genericContext.getBeanFactory();

// création du bean datasource et injection de ses propriétés
BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.rootBeanDefinition(DriverManagerDataSource.class); beanDefinitionBuilder.addPropertyValue("url", driverDataSource.getUrl());
beanDefinitionBuilder.addPropertyValue("password", driverDataSource.getPassword());
beanDefinitionBuilder.addPropertyValue("username", driverDataSource.getUsername());
beanDefinitionBuilder.addPropertyValue("driverClassName", "oracle.jdbc.OracleDriver");

// enregistrement du bean dans le contexte parent
beanFactory.registerBeanDefinition("parentDataSource", beanDefinitionBuilder.getBeanDefinition());
genericContext.refresh();

// création du contexte de l'API comme contexte enfant
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] { "engine-context.xml", "service-context.xml", "dao-context.xml" }, true, genericContext);

// déclare le bean courant comme autowired
context.getAutowireCapableBeanFactory().autowireBeanProperties(this,AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, false);

// initialise le bean courant en y injectant les beans
context.getAutowireCapableBeanFactory().initializeBean(this,"modeDataEngine");
}

Contexte Spring

La ligne suivante définit une dataSource dans le contexte de l'API.

<bean id="datasource" parent="parentDataSource">


Quelques remarques

La datasource utilisée est une DriverManagerDataSource fournie par le framework Spring. Pourquoi est-ce la seule utilisable?
Pour définir une datasource dans un contexte, nous avons besoin de lui fournir plusieurs données pour s'initialiser:
  • l'URL de connexion,
  • la classe du driver JDBC,
  • le nom d'utilisateur,
  • Le mot de passe.
Le DrvierManagerDataSource est une classe qui permet d'obtenir ces informations en utilisant de simples setter, ce qu'un grand nombre d'implémentation de l'interface DataSource ne font pas.
L'objectif est de proposer une API, ce qui implique qu'elle ne doit prendre en entrée, pour rester flexible, que des interfaces ou des classes définies par l'API elle-même.

Utilisation d'une factory

Une autre solution consiste à créer une factory de DataSource.
L'idée est de fournir une dataSource, n'importe quelle implémentation, à la méthode d'initialisation de l'API, qui ensuite, chargera le contexte Spring. Dans ce contexte, une factory doit être définit. Elle doit définir une méthode d'initialisation, qui ira chercher la dataSource dans l'instance de l'API, puis la fournira aux autres beans.

Contexte Spring

<bean id="dataSourceFactory" class="DataSourceFactory" method="init">

<bean id="dataSource" bean="dataSourceFactory" method="getDataSource">