Google Plugin For Eclipse

Google fournit un plugin Eclipse pour la création d'applications web basées sur Google Web Toolkit et permettant de déployer les applications sur Google App Engine. Petit tour d'horizon de ce plugin bien pratique.

Installation

Pour installer le plugin, deux URLs sont disponibles suivant la version d'Eclipse:

• Version 3.3: http://dl.google.com/eclipse/plugin/3.3
• Version 3.4: http://dl.google.com/eclipse/plugin/3.4

Le plugin install la version 1.6.4 de GWT et la version 1.2.1 du kit Google App Engine par défaut.

Création d'un projet

La création se fait via le wizard en passant par le menu: File > New Project > Web Application Project ou en utilisant le bouton

Le wizard permet d'inclure/exclure GWT et/ou Google App Engine dans le projet. Il inclut par défaut les dernières versions des frameworks. Via les liens Configure SDKs... , il est possible de choisir une autre version du SDK installée sur la station.

GWT

MyTestProject
src/
com/
mytestproject/
MyTestProject.gwt.xml
client/
GreetingService.java
GreetingServiceAsync.java
MyTestProject.java
server/
GreetingServiceImpl.java
war/
MyTestProject.css
MyTestProject.html
WEB-INF/
web.xml
classes/
lib/
...GWT JARs...       

Le plugin génère une application de base avec un service RPC de base. L'application permet d'envoyer une message via le service. Et celui-ci renvoi ce message avec des informations sur le serveur.
Pour le service, l'interface, les implémentations coté client et coté serveurs sont générés.

Google App Engine

MyTestProject
src/
log4j.properties
META-INF/
jdoconfig.xml
com/
mytestproject/
MyTestProjectServlet.java
war/
index.html
WEB-INF/
appengine-web.xml
web.xml
logging.properties
classes/
lib/
...App Engine JARs... 

L'application générée donne accès à la technologie de persistance DataNucleus utilisée par GAE. Pour la partie présentation, puisque l'application est censé être une appli web, une servlet a été généré.
Le fichier appengine-web.xml permet de configurer le déploiement de l'application. Le fichier jdoconfig.xml contient la configuration du framework DataNucleus.

GWT et GAE

MyTestProject
src/
log4j.properties
META-INF/
jdoconfig.xml
com/
mytestproject/
MyTestProject.gwt.xml
client/
GreetingService.java
GreetingServiceAsync.java
MyTestProject.java
server/
GreetingServiceImpl.java
war/
MyTestProject.css
MyTestProject.html
WEB-INF/
appengine-web.xml
web.xml
logging.properties
classes/
lib/
...App Engine JARs...
...GWT JARs...

L'application offre des fonctionnalités similaires aux deux types de projet précédents.

Exécuter l'application en hosting mode

L'exécution de l'application en hosting mode, mode qui permet d'utiliser le debuger, il suffit de faire click droit sur le projet puis: Run As... > Web Application.
La console, qui permet de monitorer l'activité serveur, s'ouvre:

Puis le hosted browser, un navigateur intégré:

Remarque: il est prévu pour la version 2 de GWT, que le hosted browser soit remplacé par le navigateur par défaut du système hôte.

Déployer l'application Google App Engine

Le déploiement d'une application GAE se fait simplement en clickant sur l'icône pour ouvrir la boite de dialogue:
Il faut posséder un compte GAE pour pouvoir déployer une application, et donc posséder un compte utilisateur Google. Le plugin doit d'abord être configuré avec l'identifiant de l'application GAE: Properties > Google > App Engine > Application ID. Aprés avoir clické sur le bouton Deploy, le plugin compile et package l'application, qui est ensuite envoyée sur la plate forme.
L'application est alors utilisable.

Conclusion

Malgrés la possibilité d'intégrer les outils de GWT tel junitCreator comme outil externe d'Eclipse, je regrette l'abscence de ces outils du plugin. La volonté de Google était apparement de fournir le plus rapidement possible un outil permettant de developper des applications GWT. Du coup, le nice to have a été mis de coté. Ce sera, je l'espére, pour la prochaine version. La raison de cette abscence peut aussi être expliqué par les bugs (dans la version 1.6.4 du SDK) produits par ces scripts.

Effective Java, Second Edition par Joshua Bloch

En décembre 2008, Joshua Bloch a participé au deuxiéme keynotes de Devoxx. Il en a profité, en se basant sur ce livre, pour nous mettre les méninges en ébulition.
C'est donc avec curiosité que je me suis plongé dans cet ouvrage. Je pensais n'y trouver qu'une discussion sur la bonne pratique du langage Java, un peu comme c'était le cas lors de Devoxx. En réalité, le discours est plus accès sur le design et la résolution de problémes de conceptions.
Le livre est organisé par thématiques qui couvrent des sujets aussi "anodin" que l'utilisation des constructeurs, jusqu'à des sujets plus pointus comme la concurrence. Chaque thématique est abordé suivant des problémes, items, auxquels le développeur est continuellement confronté. Pour chaque item, une ou plusieurs solutions sont exposées, et les avantages/inconvénients y sont discutés.
Effective Java pourrait être rebatiser: pour un meilleur développement.

Introduction à Spring ROO

Introduction

Lors du premier keynotes de SpringOne Europe, Ben Alex a fait une démonstration d'un outil permettant de démarrer from scratch un nouveau projet: ROO. C'est un outil de génération de code basé sur les produits Spring, Maven et AspectJ.
Nous allons créer une application web permettant de gérer une liste d'employés.

Premier contact

ROO n'étant qu'en version alpha 2, il n'est pas directement disponible à partir de la page de download de Spring. le bundle est disponible à l'adresse suivante: http://dist.springframework.org/milestone/ROO/spring-roo-1.0.0.A1.zip

ROO se présente sous la forme d'un shell:

La commande hint du shell permet d'obtenir de l'aide par rapport à l'état d'avancement du projet. Par exemple, si aucun projet ROO n'ext contenu dans le répertoire courant, la commande de création de projet est proposé:

La touche TAB peut également fournir une aide. Lorsque c'est possible, elle complète la commande à votre place, ou, elle propose une liste des champs possibles.

Remarque: La commande exit permet de sortir du shell.

Création du projet

ROO ne crée pas le répertoire racine du projet, il faut donc le faire à la main:
mkdir spring_roo
cd spring_roo

La commande suivante permet de créer le contenu du projet sous la forme d'un projet Maven:
create project -topLevelPackage net.techwatch.spring.roo

Remarque: Pour transformer le projet en projet Eclipse, il suffit d'exécuter la commande Maven:
mvn eclipse:eclipse

Il est également possible d'ajouter les logs par:
configure logging -level DEBUG

Avant la création des entités du model de données, il faut intégrer le support de JPA à notre application:
install jpa -database HYPERSONIC_IN_MEMORY -provider HIBERNATE

et créer les classes du domaine:
new persistent class jpa -name ~.domain.Employee
add field string -fieldName firstName -notNull
add field string -fieldName lastName -notNull
add field date jpa -fieldName birthDate -type java.util.Date

new persistent class jpa -name ~.domain.EmployeeList
add field string -fieldName name -notNull
add field string -fieldName comment -sizeMax 254
add field date jpa -fieldName date -type java.util.Date
add field set jpa -element Employee -fieldName employee

La création d'un élément persistent se fait par la commande:
new persistent class jpa -name

Remarque: Le caractère ~ fait référence au package root de l'application.

Le type du champ fait partie de la commande, par contre, les contraintes sont considérées comme des options. L'utilisation d'un type date nécessite de spécifier l'implémentation à utiliser: java.util.Date ou java.sql.Date.
L'utilisation de l'option -sizeMax est une utilisation de l'implémentation de la JSR 303 (Bean validation). A l'exécution, ROO utilise ses annotations pour vérifier les contraintes.

Remarque: il est possible d'ajouter un champ dans n'importe quelle entité en utilisant l'option -class de la ligne de commande.

Exemple de code généré pour l'entité Employee:
@Entity
@RooEntity
@RooJavaBean
@RooToString
public class EmployeeList {

@NotNull
private String name;

@Size(max = 254)
private String comment;

@Temporal(TemporalType.TIMESTAMP)
private Date createDate;

@OneToMany(cascade = CascadeType.ALL)
private Set employee = new HashSet();
}

L'annotation RooToString ajoute une définition de la méthode toString. L'annotation RooJavaBean se charge d'implémenter les méthodes d'accès et RooEntity permet d'implémenter, entre autre, la validation des contraintes.

Pour compléter l'application, il faut maintenant implémenter le modéle MVC d'une application web. ROO permet d'implémenter cette architecture en se basant sur Spring WebFlow et Spring MVC. Des composants Ajax, basés sur le framework Dojo, sont également intégrés aux pages JSP.

new controller automatic -name ~.web.EmployeeListController
new controller automatic -name ~.web.EmployeeController -formBackingObject ~.domain.Employee

L'utilisation du paramétre automatic permet de générer la totalité de la logique des controlleurs, sinon, son développement est à la charge du développeur.
ROO, lors de la création des controlleurs, ajoute l'option -formBackingObject avec une référence sur la dernière entité utilisé. Cette option permet de faire le lien avec l'entité JPA pour le stockage des données du formulaire.

Exemple de code pour un controlleur:
@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = Employee.class)
@RequestMapping("/employee/**")
@Controller
public class EmployeeController {
}

L'annotation RooWebScaffold permet de faire le mapping entre l'entité et la vue (un peu à la façon dont Grails fonctionne). RequestMapping permet d'établir la concordance entre les URLs et les controlleurs.

Remarque: l'application utilise des URL Rest.

Il ne reste plus qu'à exécuter l'application:

SpringOne Europe 2009: ou comment sauver Java

Nous sommes sauvés

Premier key notes, rencontre avec Rob Johnson, le père de Spring. Comme entrée en matière, il a choisit de parler de ce qui nous inquiète tous: le rachat de Sun par Oracle. Rob souligne l'attitude de suiveur qu'à toujours eu Sun dans le développement de la plate forme, et que, Java est devenu open source, qu'il n'y a donc pas à s'en faire: les innovations vont continuer comme avant, apporté par d'autres sociétés/communautés. Et puis, il ne faut pas s'en faire, SpringSource est là...
A ce demander s'il na pas raison, vu le nombre de développeurs participant à des JSR de JEE 6.
Ensuite, il continue en parlant de la difficulté qu'ont les développeurs de démarrer un projet rapidement, de mettre en place les environements adéquats et conclut en présentant Spring Tool Suite et ROO, en comparant cette offre à celle de la plate forme .NET. Un peu prétentieux non...

Le contenu

Le contenu de la majeur partie des conférences ressemblait à un résumé de la documentation en ligne. Toutefois, certains projets ont su se mettre en valeur parmis lesquels:

• tc server: un serveur Tomcat associé à une console digne de la console d'administration WebSphere. Elle intégre des outils de monitoring.
• Spring Faces: Début de l'intégration de JSF 2.0. Intégre le framework JavaScript DOJO permettant d'intégrer des composants graphique avancés (Spring JavaScript). Ce framework utilise Spring MVC à la place des Manage Bean.
• Spring RESTFul: une implémentation REST basée sur Spring WebFlow et Spring MVC.
• Groovy: Un langage que l'on ne présente plus... La conférence sur les DSL en Groovy n'était en fait qu'un copié/collé de la conférence servant d'introduction au langage. Dommage, sachant que la facilité d'implémenter des DSL dans ce langage en est le principal intéret.

En conclusion

Une certaine déception, tout d'abord. Étant plutôt habituer aux rassemblements de geek, c'est une drôle d'impression de se retrouver dans une salle remplie de costumes cravates. L'événement était clairement orienté business et destiné à en mettre plein la vue. Il suffit pour cela de voir l'endroit dans le quel SpringOne a était organisé. Malgrés le standing de l'hotel, je ne peut que déplorer le manque de café ou de rafraichissement entre les conférences.
Le moment le plus intéressant de l'événement fut sans doute lundi soir, le repas qui été organisé permettait de discuter avec les différents intervenants et d'échanger des idées, ce qui, même lors d'événements comme Devoxx est assez rare, et particulièrement appréciable.

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?

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">