Catégorie: Spring

Bonsoir,

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

Fervent utilisateur d'IntelliJ Idea depuis un moment déja, je me suis empressé de télécharger la beta une fois sortie pour tester cela et je ne suis pas déçu

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

Comme vous le savez peut-être l'internationalisation à base de ResourceBundle ne supporte que des fichiers .properties encodé en ISO-8859-1, il faut donc encoder les caractères spéciaux sous la forme \uxxx ce qui n'est pas très lisible lorsque vous utilisez des languages comme l'arabe ou le chinois. De plus, si vous voulez ou devez utiliser des fichiers .properties encodés en UTF-8 vous êtes bloqués dès que vous devez utiliser des caractères spéciaux.

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 :

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource"> 
   <property name="basenames"> 
      <list> 
        <value>classpath:org/project/i18n/messages</value> 
        <value>classpath:org/project/i18n/errors</value> 
     </list> 
   </property> 
   <property name="cacheSeconds" value="-1" /> 
   <property name="fileEncodings" value="UTF-8" /> 
   <property name="defaultEncoding" value="UTF-8" /> 
</bean>

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

Depuis un moment, j'utilise Spring sans XML en Java SE comme djo-mos l'a presenté avec un ClassPathBeanDefinitionScanner.

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

» Lire la suite!