Une petite nouvelle pour l’avancement du projet JTheque.

J’ai commencé à migrer JTheque Core vers un environnement OSGi et Spring Dynamic Modules. Le core sera désormais séparés en plusieurs bundles par fonctionnalité.

Les modules seront aussi des bundles OSGi.

Ce changement permettra d’améliorer la modularité des différents éléments du core et de suivre une voie plus standarde pour la création de modules.

J’espère que cela permettra d’améliorer la qualité de JTheque Core. C’est également une occasion pour moi d’apprendre à utiliser OSGi et Spring DM.

Baptiste

Au niveau des performances, JetBrains a tenu sa promesse, la nouvelle version démarre plus rapidement, freeze beaucoup moins et est plus réactive.

Au niveau de l’interface, il n’y a apparemment pas d’énormes changements. Certaines barres d’outils ont été revues de manière plus logique et on trouve plus facilement ce que l’on veux.

La vue « Project » a été revue pour afficher la hiérarchie des modules pour un projet Maven, ce qui est assez agréable.

Les vues de configuration possèdant une longue zone de texte ont été revues pour n’avoir de barre de défilement que sur la zone de texte, ce qui permet de garder en vue les options de la colonne de gauche constamment.

Mais sinon, pas de grosses révolutions de ce côté-là.

Au niveau des inspections, la vue a été allégée est plus agréable, mais surtout, et plus important, les inspections ont été améliorées. Ainsi à inspection égale, on trouve plus d’erreurs. En plus de cela, de nouvelles inspections ont été ajoutées, notamment au niveau de Maven et OSGi.

En plus de cela, on voit maintenant l’apparition d’un correcteur orthographique des plus pratiques. Ce dernier permet de vérifier l’orthographe dans les commentaires, les noms de variables, les noms des méthodes, les fichiers annexes, … C’est très pratique surtout pour quelqu’un comme moi qui ne suis pas de langue anglaise mais qui documente en anglais. De base, seul un dictionnaire anglais est fourni, mais il est possible de rajouter des dictionnaires au format .dic.

Et enfin, une amélioration certaines de performances et de l’efficacité du plugin Subversion

C’est tout ce que j’ai pu constater pour le moment en n’utilisant que tout ce qui est Java SE.

Sinon, dans ce qui a l’air intéressant, mais que je n’ai pas encore testé :

• La gestion de contexte : On peut enregistrer des contextes, par exemple développement sur telle ou telle branche, modules, … En enregistrant un contexte, on enregistre les éditeurs ouverts, les breakpoints, les objets déroulés dans la vue « Project », …
• Le développement avec OSGi

Pour le moment, je suis en tout cas très satisfait de cette nouvelle mouture

Une première solution est de passer par des fichiers XML en spécifiant l’encodage UTF-8.

Néanmoins, Spring propose une solution avec la classe ReloadableResourceBundleMessageSource. En effet, avec cette classe on peut spécifier l’encodage utilisé pour les fichiers directement dans le mesageSource. En plus de cela, cette classe suppporte également le rechargement des fichiers properties soit à intervalle régulier soit en utilisant la méthode clearCache().

Il faut faire attention en passant à cette classe que les liens vers le(s) basename(s) se fait en utilisant des ressources Spring, donc en suivant la nomenclature de ces dernières.

Voici un exemple d’utilisation avec Spring :

Mettre cacheSeconds à -1 permet d’indiquer de ne pas chercher à recharger les fichiers .properties.

Toutes mes classes étaient annotés avec Service, Component, Repository pour être détectés au scan et j’ajoutais aussi directement des beans dans le context. Cela marche très bien, mais on est vite assez limité, par exemple si on veut utiliser AOP, Spring Transaction, …

J’ai donc cherché sur internet une solution et je suis tombé sur une perle : Spring JavaConfig, développé par SpringSource

Cette fois, on remplace le fichier de configuration XML par une classe annnotée avec @Configuration. C’est dans cette classe qu’on va déclarer nos beans.

Voici un exemple de classe :

Il est intéressant de développer les choses suivantes :

• @Configuration(defaultLazy = Lazy.TRUE) : Toutes les classes de configuration doivent être annotées de cette façon pour être comprises pour comme configuration Spring. On peut spécifier des paramètres de Spring via les attributs de l’annotation, comme par exemple utiliser une initialisation lazy pour la création des beans
• @ImportXML(« classpath:test/datasource-config.xml ») : Permet d’importer le contenu d’un fichier de config XML
• @ComponentScan(« test.services ») : Permet de scanner le contenu du package test.services
• @AnnotationDrivenTx(transactionManager= »txManager ») : Permet d’utiliser Spring transaction avec les annotations et de déclarer le transaction manager.
• @Bean : Permet de déclarer un bean. Le nom de la méthode sera le nom du bean.

On peut ensuite obtenir le contexte de la manière suivante :

JavaConfigApplicationContext context = new JavaConfigApplicationContext(ApplicationConfig.class);

et l’utiliser comme n’importe quel applicationContext habituel

Dans un soucis de modularité, on peut également passer plusieurs classes au constructeur de JavaConfigApplicationContext.

Cette librairie a quelques prérequis :

• Java 5.0 or higher
• Spring 2.5.6 or higher
• AspectJ 1.6.2 or higher
• CGLIB 2.1.3

Cette librairie est disponible en version 1.0.0.M4.

Personnellement, je trouve cette façon de faire très élégante. On peut faire tout ce qu’il y a dans un fichier XML de manière programmatique, pour ceux qui préfère la méthode programmatique, je trouve que c’est très intéressant

Pour plus d’infos, je vous inviter à consulter la page officielle : http://www.springsource.org/javaconfig