Il s’agit de controler l’inclusion de fichiers de configuration Spring via une property passé à la JVM :

<import resource="${env}-infrastructure.xml"/>

puis passer l’argument :

-Denv=prod

ou encore

-Denv=dev

Par exemple, selon que l’on est en mode développement ou en mode production.

J’adore ! surtout pour l’inclusion des fichiers .properties

Le billet qui présente cette technique.

Dans un programme Java ordianire, log4j cherche un fichier log4j.properties (ou xml) dans le racine du classpath. Or, dans un conteneur OSGi, la notion de classpath est différente. On n’a plus de classpath unique par application, mais plutôt un classpath séparé par bundle.

Pour résoudre celà, on utilise la notion de fragments. Un fragment est un bundle spécial, qui à l’exécution (à la pahse de resolution), se trouve attaché et mergé dans un autre bundle hôte. Après, il sera traités exactement comme faisant partie du bundle hôte.

Dans le cas précis de ce billet, on va créer un fragment avec le bundle de log4j comme hôte, et on va placer le fichier log4j.properties dans ce fragment.
Ainsi, quand log4j va rechercher un fichier de configuration dans la racind du classpath (le classpath de son bundle), il trouvera et utilisera ce fichier

Eclipse PDE fournit un assistant pour la création d’un fragment. Faites « New > Other > Plug-In Developement > Fragment Project » :

Saissisez un nom pour ce fragment, « ssosgi.log4j.config » dans mon cas par exemple et cochez l’option « an OSGi framework » sous « Target Platform »:

Dans la page suivante, utilisez le bouton « Browse » pour sélectionnez le bundle de log4j comme Host Plig-In

Et validez.

Dans le projet, créez un fichier log4.properties avec le contenu suivant :

log4j.rootLogger=info, con, file 

log4j.appender.con=org.apache.log4j.ConsoleAppender 

log4j.appender.con.layout=org.apache.log4j.PatternLayout 

log4j.appender.con.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n 

 

log4j.appender.file=org.apache.log4j.FileAppender 

log4j.appender.file.layout=org.apache.log4j.PatternLayout 

log4j.appender.file.layout.ConversionPattern=%5p [%t] (%F\:%L) - %m%n 

log4j.appender.file.File=/home/djo/ssosgi.log 

log4j.appender.file.append=false

Notez que vous pouvez personnaliser la configuration pour l’adapter à vos besoins. Pensez notamment à changer le nom du fichier de log («/home/djo/ssosgi.log» dans mon cas).

Il faut ensuite ajouter ce fragment à la configuration de lancement. Allez dans la fnêtre de configuration de celle-ci (comme décrit dans le billet précédent) et cochez le fragment qu’on vient de créer dans la liste des plugins à inclure.

Appliquez et lancer la configuration. Vous devriez avoir un log plus détaillé dans la console d’Eclipse :

Dans ce premier billet, je vais présenter l’étape de préparation de l’environnement de développement,et plus particulièrement la notation de Target Platform.

1. Présentation

Il s’agit ici de définir l’ensemble initial de plugins qui va constituer l’environnement d’exécution de notre serveur.

Il nous faut aussi configurer Eclipse pour qu’il reconnaisse et travaille sur cet ensemble de plugins.
Ca permettrait d’une part de limiter le nombre de choix présentés dans divers endroits (lors de sélection de plugins requis et des packages importés, des plugins à inclure dans une configuration d’exécution, etc.) mais aussi pour éviter une dépendance accidentelle à un plugin non désiré (je pense notamment aux plugins d’Eclipse par exemple)

2. Vue d’ensemble

La target platform sera constituée de :

• Equinox : C’est le coeur du serveur. Il implémente les spécifications OSGi et servira comme conteneur qui charge et gère le cycle de vie des autres plugins
• Spring Dynamic Modules : C’est une sorte de pont entre le monde OSGi (registre des services) et le monde de Spring (application context). De plus, Spring DM permet de faire tourner des applications Web Java ordinaires (Servlets, JSPs, etc.) dans un conteneur OSGi (OSGi offre un support basique pour le web à travers HttpService, mais c’est très limité)
• Spring : Il est là car tout d’abord il est requis par Spring DM, mais aussi pour son moteur IoC ainsi que les abstractions qu’il offre au dessus de plusieurs technologies Java (JDBC et Remoting entre autres)
• Jetty : Comme énoncé plus tôt, le HttpService d’OSGi est très limité parapport à la puissance dont on dispose dans une application web Java ordinaire. J’ai donc inclus Jetty dans la configuration de base de notre serveur pour avoir toute la puissance requise sous la main
• Quelques autre dépendances, comme des librairies de logging

Notez qu’il est tout à fait possible (et très simple) d’utiliser Tomcat à la place de Jetty. Ceci revient juste à remplacer les jars de Jetty par ceux de Tomcat.

3. Récupération des fichiers nécessaires

Il va nous falloir télécharger plusieurs packages pour retrouver les jars nécessaires.

• Spring DM : récupérable à cette adresse (pour cet article, j’ai utilisé Spring DM 1.2 M2)
• Spring Framework : récupérable à cette adresse (pour cet article, j’ai utilisé Spring Framework 2.5.6)

Après avoir extrait les archives de Spring et de Spring DM, Créez quelque part sur votre disque un dossier qui servira à rassembler les jars de la target platform, par exemple  » server-springdm-1.2.0.m2-spring-2.5.6-jetty  » dans mon cas.

Généralement, je crée la target platform en tant que projet (simple) dans mon worksapce Eclipse, histoire de pouvoir le versionner sur SVN par exemple, mais ce n’est pas requis.

Copiez les fichiers suivants depuis le dossier où vous avez extrait Spring DM vers le dossier de la target platform:

• spring-osgi-1.2.0-m2/dist/spring-osgi-core-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-extender-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-io-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-extender-1.2.0-m2.jar

• spring-osgi-1.2.0-m2/lib/com.springsource.net.sf.cglib-2.1.3.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.org.aopalliance-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.api-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.log4j-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.org.apache.commons.logging-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.start.osgi-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-util-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.web.extender.fragment.osgi-1.0.1.jar
• spring-osgi-1.2.0-m2/lib/log4j.osgi-1.2.15-SNAPSHOT.jar
• spring-osgi-1.2.0-m2/lib/org.eclipse.osgi-3.2.2.jar
• spring-osgi-1.2.0-m2/lib/servlet-api.osgi-2.5-SNAPSHOT.jar

• spring-framework-2.5.6/dist/modules/spring-aop.jar
• spring-framework-2.5.6/dist/modules/spring-beans.jar
• spring-framework-2.5.6/dist/modules/spring-context.jar
• spring-framework-2.5.6/dist/modules/spring-core.jar
• spring-framework-2.5.6/dist/modules/spring-jdbc.jar
• spring-framework-2.5.6/dist/modules/spring-tx.jar
• spring-framework-2.5.6/dist/modules/spring-web.jar
• spring-framework-2.5.6/dist/modules/spring-webmvc.jar

Pour vous simplifier la tache, vous pouvez télécharger cet archive zip (5 Mo) qui contient la target platform décrite plus haut)

4. Configuration d’Eclipse

Dans Eclipse, allez au menu Window -> Preferences et localisez le noeud « Plug-in Development/Target Platform »

Cliquez sur « Browse », localiser le dossier de la target platform et validez.

Il nous faut maintenant créer une configuration de lancement qui lance notre serveur.

Faites un clic sur le petit flêche orienté vers le bas du bouton Run et sélectionnez « Run configurations »

Sélectionnez le noeud « OSGi Framework », puis clic droit et « New »

Saisissez un nom pour cette configuration, « serveur » par exemple.
Par défaut, tous les plugins de la target platform sont cochés. Faites le si ce n’est pas le cas.

Assurez vous aussi que « Default start level » est positionné à 4 et que « Default-Autostart » est à true

Il faut maintenant modifer le start level des deux extenders de Spring DM (org.springframework.osgi.extender et org.springframework.osgi.web.extender) pour les mettre à 5

Cliquez sur « Apply » pour valider.

5. Test

Cliquez sur le bouton « Run ». La console devrait afficher :

Et si vous tapez l’adresse « http://localhost:8080/ » dans un navigateur, vous devriez avoir :

Aujourdhui, le second milestone de Spring dynamic Modules (spring DM) est sorti, apportant comme nouveautés :

• Passage à Spring 2.5.6
• Mise à jour des dépendances ves les modules Spring pour refléter les nouveaux noms de ceux-ci
• Support des services compendium via le namespace compendium
• etc.

Les liens qu’il vous faut :

=> Télécharger
=> Documentation
=> FAQ
=> Changelog

• Près de 100 bugs résolus
• Passage à des versions plus récentes pour des libs externes (EclipseLink, AspectJ, etc.)
• Entêtes OSGi révisées

Les liens importants :

=> Annonce
=> Documentation
=> Changelog
=> Télécharger (ça c’est pour la version community (ou gratuite), et le lien que je donne vous fait sauter un formulaire à remplir (ou a ignorer) proposé par le lien original que voici)

Je suis encore en train de lire (et relire) l’annonce, mais une chose est sûre : SpringSource est revenu sur sa décision de changer la politique de maintenance de Spring Framework, en quotant Rod Jonhson :

We are amending our maintenance policy in the light of community feedback. We will make regular binary releases from the Spring trunk available to the community, with no 3 month window. For each version of Spring, community releases will be available while it remains the trunk or until the next version is stable.

Ou en clair, l’infameuse limite des trois mois n’est plus, et des versions officielles de Spring Framework resteront toujours fournies jusqu’à ce qu’une nouvelle version majeure soit stabilisée et publiée.

Bon, pour le reste, il a aussi assuré que la licence de Spring Framework ne changerait pas ainsi qu’ils mettront en place un ajustement de la fourchette de prix pour les petites boites de développement.

Moi je trouve ça courageux de pouvoir revenir sur une telle décision mais c’est surtout bénéfique à SpringSource avant tout (peut on dire du même pour Guice ? :D) car ce qui s’était passé ces derniers mois allait (quoi que quelques dégâts sont déjà faits) laisser des séquelles sur la user-base de Spring Framework.

De plus, je suis fier de voir comment une communauté peut se dresser de la sorte pour exprimer ce qu’elle pense et aller même à changer le sort des choses. Kudos !

P.S. : L’annonce officielle en Anglais.

La paperasse officielle (ou plutôt les octets officiels ) à propos de ceci :

=> L’annonce
=> La nouvelle politique de maintenance

Bon, la nouvelle politique dit que les bug fixes et compagnie commités après ces fameux trois premiers mois seront inclus dans la version majeure suivante de Spring …

Ceci a bien évidemment suscité une vive polémique (voire même un mouvement de panique) dans la communauté, comme en témoigne la discussion suivante sur The Server Side …
Entre autre, on se posait la question judicieuse de ce que veut dire au juste version majeure …

Marc Brewar, le Vice Président Sénior de SpringSource est ensuite intervenu pour expliquer qu’une version est considérée majeure quand l’un des deux premiers chiffres de la version change (Spring utilise un schéma de versionnage à 3 chiffres). Donc, pour Spring 3.0, Spring 3.1 ou Spring 4.0 sont considérés comme versions majeures. Ouf ! Ca semble un peu moins sombre tout d’un coup …

Rod Jhonson est lui aussi intervenu dans la discussion où il présenté les choses autrement (il sait bien présenter lui ) : En gros, ce changement de politique internvient car avec la multiplication du nombre de versions de Spring utilisés en production augmente, SpringSource ne peut pas continuer à les supporter tous (principalement les back-port de correctifs et fonctionnalités d’une version plus récente à une autre plus ancienne). Or, pour des ceux utilisant Spring et qui ne veulent pas passer toujours à la dernière version de ce dernier (ce qui est normalement le cas avec les entreprises commerciales uniquement), ils peuvent continuer à disposer des correctifs sur ces anciennes version de Spring moyennant un abonnement dans leur programme payant.

Avis personnel : Vu comme ça, c’est pas si mauvais que ça pour la communauté Opensource utilisant Spring. Seul hic … et comme toute entreprise commerciale désirant faire des revenues (c’est leur droit naturellement), je crains que des patchs/nouvelles fonctionnalités ne soient retenues jusqu’à l’écoulement de ces 3 premiers mois …
Ou moins « théorie du complot », disons qu’un bug majeur/brêche de sécurité soit découvert après les 3 premiers mois (ce qui n’est pas du tout invraisemblable : un brêche majeure de sécurité dans Spring MVC a été découverte plusieurs mois après sa sortie), et que la version majeure suivante n’est pas prévue avant encore 6 mois (toujours pas si invraisemblable)… doit on vivre avec ça durant ces 6 mois ?

Bien que je suis profondément deçu par cette décision de SpringSource, je peux parfaitement comprendre leurs motivations : ils ont des employés à payer, ne l’oublions pas, et c’est leur droit de vouloir gagner de l’argent. Ce n’est pas moi qui travaille dans une société commerciale qui développe et vend des applications qui vais m’en offusquer.
Ce qui m’offusque c’est plutôt :

• SpringSource communique très mal la dessus … l’annonce et le texte du changement de politique sont très brefs, vagues, sujet à plusieurs interprétations, surchargés de choses inutiles, etc. Il sauraient pu mieux communiquer cette action au lieu de la clarifier ensuite sur des forums …
• Mais surtout les changements de politique en cours de route. Ca sape la confiance de la communauté dans le produit. Spring Framework a reçu un coup dûr avec cette dernière action, surtout dans le monde des entreprises : C’est devenu un framework à risque, rien n’empêcherait la licence de Spring Framework (Apache 2) de changer dans le futur par exemple …

Conclusion du jour : vais commencer à étudier Guice, on ne sait jamais

=> Exprimez vous dans cette discussion sur le forum !

Edit: Apparamment, les bugfixes et autres seront toujours commités dans le trunk public de Spring, même après le délai des 3 premiers mois (Source : commentaire de Marc Brewar sur ce blog). Seulement, SpringSource ne publierait plus des releases officiels que pour ses abonnés. Mais il reste possible de récupérer la dernière version du trunk et la recompiler à la main.
Seul hic, et avec la communauté Java (sur-zélé :p), ceci va causer une avalanche de versions exotiques de Spring venant d’une multitude de sources sur le net … bonjour les dégâts … ça va chauffer pour le repository de maven

P.S.: Drôle de coïncidence, Peter Mularien vient de publier une étude sur la transparence de Spring Framework …
P.S. 2 : Alexis MP vient de publier un billet sur ce thème.

Donc, suite à quelques recherches et expérimentations, j’ai pu mettre en place un autre filtre beaucoup plus solide qui permet d’intercepter les erreurs de sessions expirées dans JSF (qui sont plus qu’abondants avec ce dernier ) pour afficher une page personnalisée au lieu de la mooche page d’erreur par défaut du serveur utilisé.

En gros, voici une version simplifiée du filtre :

import java.io.IOException; 

 

 

 

import javax.servlet.Filter; 

 

import javax.servlet.FilterChain; 

 

import javax.servlet.FilterConfig; 

 

import javax.servlet.ServletException; 

 

import javax.servlet.ServletRequest; 

 

import javax.servlet.ServletResponse; 

 

import javax.servlet.http.HttpServletRequest; 

 

import javax.servlet.http.HttpServletResponse; 

 

 

 

import org.slf4j.Logger; 

 

import org.slf4j.LoggerFactory; 

 

public class TimeoutFilter implements Filter { 

  private static final Logger log = LoggerFactory 

      .getLogger("webapp.timeoutFilter"); 

 

  private static final String TIMOUT_PAGE = "timeout.html"; 

  private static final String LOGIN_PAGE = "login.faces";  

 

  public void init(FilterConfig filterConfig) throws ServletException { 

  } 

 

  public void doFilter(ServletRequest request, ServletResponse response, 

      FilterChain filterChain) throws IOException, ServletException { 

    if ((request instanceof HttpServletRequest) 

        && (response instanceof HttpServletResponse)) { 

      HttpServletRequest hRequest = (HttpServletRequest) request; 

      HttpServletResponse hResponse = (HttpServletResponse) response; 

 

      if (checkResource(hRequest)) { 

        String requestPath = hRequest.getRequestURI(); 

        if (checkSession(hRequest)) { 

            String timeoutUrl = hRequest.getContextPath() + "/" 

                + TIMOUT_PAGE; 

            log.info("Session is invalid! redirecting to timeoutpage : {}", 

                    TIMOUT_PAGE); 

 

            hResponse.sendRedirect(timeoutUrl); 

            return; 

        } 

 

 

    } 

    filterChain.doFilter(request, response); 

  } 

 

  private boolean checkResource(HttpServletRequest request) { 

    String requestPath = request.getRequestURI(); 

    log.debug("reqPath={}", requestPath); 

    return !(requestPath.contains(TIMOUT_PAGE) ||  

        requestPath.contains(LOGIN_PAGE) ||  

      requestPath.equals(hRequest.getContextPath() + "/")); 

 

  } 

 

  private boolean checkSession(HttpServletRequest request) { 

    return request.getRequestedSessionId() != null 

        && !request.isRequestedSessionIdValid(); 

 

  } 

 

  public void destroy() { 

  } 

 

}

Quelques notes:

• J’utilise SLF4J pour le logging
• Je commence par vérifier s’il s’agit bien d’une requête HTTP
• Si c’est le cas, je vérifies si la ressource demandée (request.getRequestURI()) est une ressource protégée via la méthode checkResource(). En fait, c’est à vous de décider quelle ressource protéger. Dans cet exemple, je suppose que toute page exceptée celle du timeout, du login et la racine est protégée.
• Je vérifies ensuite l’état de la session en contrôlant que l’identifiant (jsessionid) est non null, et qu’il est valide
• Si c’est pas bon, alors je redérige vers la page de timeout (via request.sendRedirect)

Toutefois, cette implémentation n’est pas encore parfaite, car il peut arriver des cas où la session est valide sans que l’utilisateur ne soit authentifié.

Pour résoudre ceci, j’ajoute un autre test (après le premier) qui récupère un bean session (un managed bean JSF en fait, mais managé par Spring) pour vérifier qu’il n’est pas null et qu’un champ particulier est renseigné :

if (hRequest.getSession(false) != null) { 

 

  final WebApplicationContext ac = WebApplicationContextUtils 

 

    .getWebApplicationContext(hRequest.getSession(false).getServletContext()); 

 

  if (ac == null) { 

 

    //redériger vers la page du timeout ... 

 

  } else { 

 

    LoginCtrl loginCtrl = (LoginCtrl) ac.getBean("loginCtrl"); 

 

    if (loginCtrl == null || !loginCtrl.isLoggedIn()) { 

 

    if (!(requestPath.contains(LOGIN_PAGE) || requestPath 

 

      .equals(hRequest.getContextPath() + "/"))) { 

 

      //redériger vers la page du timeout ...        

 

    } 

 

  } 

}

Il faut juste bien vérifer de passer false à getSession : ça m’a fait perdre quelques millions de neuronnes pour comprendre ce qui se passait car j’avais ajouté cette innoncente instruction :

log.debug(hRequest.getSession(true);

erf …

Après, il est possible de peaufiner encore la chose, en ajoutant par exemple un test qui emêche un utilisateur déjà connecté de se reconnecter, i.e. d’accèder à la page de login, chose indispensable quand on bosse avec Spring par exemple, où une manipulation pareille ne recharche pas les beans en scope session …

Le serveur et le client sont architecturés comme suit:

• Le serveur est un ensemble de bundles OSGi tournant sur S2AP (beta 8) composé comme suit:
  • un bundle définissant un PAO
  • un bundle définissant l’interface d’un DAO
  • un bundle définissant une implémentation du DAO utilisant Spring JDBC, MySQL et Apache DBCP
  • un bundle exposant ce DAO pour accès distant via Hessian/Spring
• Le client est une application à base d’Eclipse RCP (3.4) qui est constitué de :
  • un bundle définissant un PAO (exactement le même que celui deployé dans le serveur)
  • un bundle définissant l’interface d’un DAO (exactement le même que celui deployé dans le serveur)
  • un bundle qui importe le DAO distant (toujours via Hessian/Spring) et l’expose en tant que Service OSGi (via Spring DM)
  • un plug-in qui définit l’aplication RCP
  • un plug-in qui ddéfinit une perspective et une vue affichant la liste des PAOs récupérés par le DAO distant tournant sur le serveur.

Ca m’a pris 2 jours (plus précisément 2 demi-journées et 1 nuit blanche), et même si le résultat est juste un proof-of-concept, sa mise en place etait vraiment douleureuse.

Je compte donc faire partager cette expérience en montrant, captures, explications et sources à l’appui, comment réaliser celà, enfin, si ça intéresse quelqu’un

Par contre, j’hésite encore sur le format : soit une série de billets dans ce blog, ou encore un article en bonne et due forme. Toutefois, ça risque de prendre du temps quand même …

<application> 

  <variable-resolver> 

    org.springframework.web.jsf.DelegatingVariableResolver 

  </variable-resolver> 

</application>

Mais maintenant, on utilise le nouveau FacesELResolver de Spring 2.5 de cette façon:

<application> 

  <el-resolver> 

    org.springframework.web.jsf.el.SpringBeanFacesELResolver 

  </el-resolver> 

</application>

Dommage que ce ne soit pas bien documenté dans Spring 2.5, et pire encore, qu’il y est une confusion sur le nom du resolver: sur le net.La seule mention à son égard est dans la page 27 du manuel de Spring 2.5, et il est nommé DelegatingFacesELResolver tandis qu’en réalité, il est nommé SpringBeanFacesELResolver.

En espérant que vous trouverez ceci utile.