Dans mon cas, ça a commencé Lundi dernier (le 22) : j’ai reçu un mail de leur part comme quoi un compte en mon nom dans leur site a été crée … je me rappelle que j’avais crée un compte il y’a une année déjà pour pouvoir télécharger leur produit. ils ont utilisé la première partie de mon adresse email comme login et un mot de passe standard.

Aujourd’hui, je viens de recevoir un second email comme quoi ils ont entendu que je travaillais sur un projet utilisant ICEfaces (wow ! moi même je le savais pas) et qu’ils voudraient me contacter (par téléphone) pour m’expliquer les avantages dont je disposerais si je m’abonne à leur programme de support commercial.

Je ne suis pas le seul, ça s’est sûr … et j’hésite sur comment je dois prendre cela je veux dire que c’est naturel qu’ils essaient de faire connaitre et adopter leurs produits … mais aussi agressivement ? me créer un compte à ma place ? Mais surtout (leur second mail) :

Hello Jawher,

I noticed that you are working on a project with ICEfaces

Edit:
En fait non, grâce à l’explication de lepack (un membre d’ICEfaces peut être ?), le fait qu’on m’ait automatiquement crée un compte dans le site d’ICEfaces est dû plutôt au fait que j’ai téléchargé la RefCard de JSF de Dzone. Or, dans la page de téléchargement, il est clairement signalé qu’en téléchargeant la chose, on serait automatiquement enrolé dans la communauté ICEfaces.

=> My bad ! J’aurais vraiment du lire plus attentivement les modalités ^^
Merci d’avoir répondu et de m’avoir rectifié !

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 …

Basiquement, il s’agit d’un scope lié à une page, où une donnée qui y est stockée est gardé trant qu’on est sur une même vue, et est effacée dès qu’on navigue vers une autre vue.

Ceux qui ont utilisé Tomahawk reconnaîtront le composant saveState qui présente une fonctionnalité simailaire.

L’introduction de ce nouveau scope est une excellente nouvelle car il serait vraiment utile (pensez aux listes alimentées depuis la base de données dans un managed bean par exemple, l’édition sur place, etc. ou on devait passer par le scope session (le marteau pour écraser la mouche)). Dommage que ça a pris 4 ou 5 ans à l’EG de JSF de s’en rendre compte

=> Annonce
=> Télécharger
=> Release Notes

Notez qu’Ed Burns (le spec Lead de JSF 2.0) a réalisé dans son blog un index de ressources parlant de JSF 2.0.
=> C’est par ici.

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

Pour ce faire, il
faut comme d’habitude déclarer le chargeur de contexte de Spring dans le web.xml, comme ceci:

<listener> 

  <listener-class> 

    org.springframework.web.context.ContextLoaderListener 

  </listener-class> 

</listener>

Ensuite, on applique au contrôleur une autre annotation comme-ci:

@Controller 

@Scope("request") 

public class TestCtrl 

: 

:

>

Il faut aussi créer l’habituel applicationContext.xml dans WEB-INF:

<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns="http://www.springframework.org/schema/beans" 

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

  xmlns:p="http://www.springframework.org/schema/p" 

  xmlns:context="http://www.springframework.org/schema/context" 

  xmlns:tx="http://www.springframework.org/schema/tx" 

  xsi:schemaLocation="http://www.springframework.org/schema/beans 

    http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 

    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd> 

 

  <!-- 

    Active la prise en charge par Spring de diverses annotations. 

  --> 

  <context:annotation-config /> 

 

  <!-- 

    Active le scan par Spring des beans pour diverses annotations. 

    On spécifie le package de base où effectuer le scan. 

  --> 

  <context:component-scan base-package="org.djo.control" /> 

</beans>

On passe à l’étape suivante (montré dans un précédent billet): L’intégration de Spring dans faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?> 

<faces-config 

    xmlns="http://java.sun.com/xml/ns/javaee" 

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd" 

    version="1.2"> 

  <application> 

    <el-resolver> 

    org.springframework.web.jsf.el.SpringBeanFacesELResolver 

    </el-resolver> 

  </application> 

</faces-config>

On crée ensuite un contrôleur (le feu managed-bean):

@Controller("test") 

package org.djo.control; 

 

public class TestCtrl { 

  private String msg = "Hello "; 

 

  //getter et setter de msg 

}

Remarquez l’annotation @Controller (stéréotype dans la terminologie Spring) qu’on a appliqué à cette classe.

Cette annotation sera interceptée par Spring (grâce à l’élément component-scan décrit plus haut et le cycle de vie de ce bean sera alors géré par Spring et non plus par l’implémentation JSF.
Ce bean sera alors exposé aux pages JSF (et partout ailleurs, comme tout autre bean managé par Spring) mais disposera en plus de tous ce que Spring offre comme la DI et la gestion des transactions, des annotations JSR 250 (gestion du lifecycle), etc.

On peut faire le test suivant dans une page JSF:

<h:outputText value="#{test.msg}" />

On aura « Hello » comme résultat si tout va bien.

Approfondissons encore la chose !
La première question qui se pose est comment contrôler le scope du contrôleur ?
Par défaut, il s’agit du scope Singleton (equivalent à ApplicationScope).
Pour pouvoir utiliser les scopes ordinaires du web (request et session), il faut déclarer un autre listener dans le web.xml:

<listener> 

  <listener-class> 

    org.springframework.web.context.request.RequestContextListener 

  </listener-class> 

</listener>

Il suffit ensuite d’ajouter l’annotation @Scope pour contrôler finement le scope d’un contrôleur:

@Controller 

@Scope("request") 

public class TestCtrl  

: 

:

Vous pouvez utiliser les scopes suivants:

• singleton
• prototype
• session
• request

Remarquez que de cette façon, il devient complètement inutile de déclarer les contrôleurs dans faces-config.xml.

Etant managé par Spring, il devient possible d’utiliser les annotations de la JSR 250 comme @PostConstruct et @PreDestroy.

Une méthode annotée avec @PostConstruct est appelée automatiquement par Spring suite à l’instantiation du bean et la satisfaction de toutes ses dépendances et une méthode annotée avec @PreDestroy est appelée automatiquement par Spring avant la destruction du bean.

La première annotation est utile par exemple dans le scénarion suivant:

Le contrôleur déclare un champ EntityDao (un DAO) comme dépendance et possède une liste List<Entity> qu’il expose aux pages JSF.
Le contrôleur ne peut pas utiliser le DAO pour initialiser la liste dans le constructeur vu que le DAO n’est pas encore injecté.

La solution est alors de le faire dans une méthode annotée avec @PostConstruct.

Ayant la chance de trvailler avec Spring, je vais plutôt vous montrer une autre façon tellement plus élégante de faire.

Voici donc la déclarartion du Bean A:

@Controller 

@Scope("session") 

public class BeanA { 

 

}

Notez l’utilisation des annotations Spring @Controller pour exposer BeanA comme managed-bean ainsi que @Scope pour spécifier que c’est stocké en session.

Maintenant, voici le bean B:

@Controller 

@Scope("session") 

public class BeanB { 

  @Resource 

  private BeanA beanA; 

  

}

Et hop !
Il suffit d’annoter le champ beanA par @Resource pour indiquer à Spring que c’est une dépendance et le tour est joué. Spring est assez malin pour injecter exactement le managed-bean de type BeanA figurant dans la même session.

J’ai survolé rapidement l’EDR, et force est de constater que c’est pas destiné pour le commun des mortels … pire encore, il est difficile de séparer ce qui est nouveau (JSF 2.0) de ce qui ne l’est pas (JSF 1.2 ou antérieurs).

Je vais donc me contenter de poster ici ce qui est promis par le groupe d’experts dans la page de la JSR:

• Fournir un mécanisme simplifié pour l’agrégation de composants: facelets ermet déjà de faire cela.
• 0 conf, ou encore plus de web.xml ni de faces-config.xml: passer par les annotations quand c’est possible
• Un mécanisme similaire au stages de Wicket (production/developement)
• Améliorer la gestion d’exceptions: il en etait temps !
• Éliminer le besoin d’écrire un TagHandler JSP pour les composants: à mon avis, meiux vaut virer complètement le JSP de l’équation
• Inclure une vraie technologie de présentation qui sera inspirée de faclets et de JSFTemplating
• Éliminer la phase déploiement: ça, c’est vraiment trop beau pour être vrai à mon avis. la solution proposée serait de passer par des scripts (au lieu de java, mais ça ne me parait pas aussi génial que ça) mais aussi changer les specs de l’Exploded WAR pour tenir compte de trucs spécifiques à JSF
• Modifier le lifecycle d’une requête pour tenir compte de l’AJAX
• Séparer « build the tree » et « render the tree » en deux phases séparés
• Permettre le traitement partiel du tree via AJAX (pour améliorer les performances)
• GET GET GET GET : le talon d’Achille de JSF: utiliser le GET autant que possible
• Validation côté client
• Une vraie fondation pour la gestion de ressources
• Ajout de quelques composants clés: Sélection de Date, upload de fichiers, arbre, onglets, etc.
• Fournir un moyen pour invoquer un traitement (via ajx si possible) au chargement d’une page
• Utilisation de deltas (liste de changements) au lieu du tree complet
• repenser la gestion d’états de composants pour rendre le stateless l’état par défaut
• Un mécanisme de communication inter-page, comme par exemple le conversational scope
• Un framework de contrôle côté client (en Java Script)
• Support du REST
• etc.

Bref, vu comme ça, ça a l’air alléchant mais attendons de voir quelque chose de concret.
Mais pour tout vous dire, j’ai vraiment été déçu par JSF 1.x : problèmes de performances, d’utilisabilité, phase de développement très pénible, trop de XML, difficulté de développement de composants (et ne me dites pas que c’est pas difficile: allez voir Wicket et on en reparlerait), etc. alors j’espère vraiment que JSF 2.0 pourrait redresser un maximum de ces défaillances.

Le Spec Lead de cette proposition, Gavin King, a récemment fait une présentation sur l’etat d’avancement actuel des WebBeans en Australie (vidéos disponibles ici).
En se basant sur ces vidéos, ce billet va présenter rapidement les principales fonctionnalités des WebBeans.

Le but des WebBeans est de:

• proposer un modèle de programmation à état ou contextuel compatible avec les EJBs et les managed beans.
• proposer un modèle extensible.
• pouvoir bénéficier de lookups (JNDI), de DI et de résolution via EL.
• un modèle conversationnel pour le web.
• Bénéficier d’interceptors (sous partie d’AOP)
• un modèle evenmentiel.
• Intégration avec JSF, JPA et les servlets.
• Intégration avec la notion de profiles du futur Java EE 6

En ce qui concèrne la compatibilité, les WebBeans devraient permettre de:

• pourvoir transformer un EJB en WebBean par le simple ajout d’une annotation
• pourvoir transformer un Managed Bean en WebBean par le simple ajout d’une annotation
• un WebBean peut intéropérer avec les EJBs
• un EJB devrait interopérer avec les WebBeans

Assez de théorie maintenant, et place à un peu de pratique.

Voici un exemple de WebBean tout simple:

public @Component class Hello {
	public String hello(String name){
		return "Hello "+name;
	}
}

Notez l’annotation @Component (identique à celui de Spring) qui permet d’exposer une classe en tant que WebBean.

Voici maintenant une classe qui utilise le bean qu’on vient de définir (Hello)

public @Component class Printer {
	@Current Hello hello;
	
	public void print(String name){
		System.out.println(hello.hello("World"));
	}
}

Tout comme Hello, Printer est un WebBean (@Component) mais qui plus est, bénéficie de DI (Injection de Dépendances) et a son membre hello automatiquement injecté par le conteneur, grâce à l’annotation @Current.

La DI va encore plus loin avec la DI par constructeur, i.e. quand on définit un WebBean sans constructeur par défaut, il conteneur va injecter tous les paramètres du constructeur.
Enfin, y’a aussi la DI via méthode d’initialisation, où on définit les diverses dépendances comme paramètres à une méthode annotée par @Initializer, et le conteneur fera le reste.

Une fois défini, un WebBean peut être nommé pour pouvoir y accéder depuis l’EL par exemple:

public @Component @Named("hello") class Hello {
	public String hello(String name){
		return "Hello "+name;
	}
}

Notez l’annotation @Named pour spécifier le nom,

<h:commandButton action="#{hello.hello}" />

Maitenant, pour ce qui est du lookup, c’est à dire comment laisser le client choisir une implémentation à injecter depuis plusieurs autres, WebBeans y va à coupe de TypeSafety (à la Guice), c’est à dire qu’on utilise des types plutôt que des chaines. => C’est le Type Binding.
Justement, le @Current est un Type Binding, ou plutôt le Type Binding par défaut.

Par exemple, si on définit un nouvelle implémentation de Hello, du genre:

public @Casual @Component class Bonjour extends Hello {
	public String hello(String name){
		return "Bonjour "+name;
	}
}

où @Casual est une annotation qu’on définit soi-même, et que dans le client (Printer) on utilise @Casual au lieu de @Current, alors c’est la classe Bonjour qui se retrouve injectée au lieu de Hello.

Seuelemnt, cette approche nécessite de modifier et de recompiler son code pour changer d’implémentations, entre la phase développpement par exemple et la phase de production.
Ca empire encore dans un grand projet, où on dénombre des centaines/milliers de telles injetions.

C’est là qu’entrent en jeu les Deployment types et le @Current.

Il faut procéder comme suit:
– Annoter toutes ses dépendances par @Current.
– Annoter les implémentations possibles par divers Binding Types, par exemple @Mock lors du développement/test et @Production pour la production.
– Ajouter un framgement XML qui spécifie quels Binding Types utiliser pour résoudre les ambiguités et dans quel ordre le faire.

<web-beans> 

  <component-types> 

    <component-type>javax.webbeans.Production</component-type> 

    <component-type>djo.types.Mock</component-type> 

  </component-types> 

</web-beans>

Place maintenant aux scopes. Comme enoncé plus tôt, les WebBeans peuvent accéder aux scopes web ainsi qu’à d’autres.
Le choix du scope se fait en ajoutant une annotation comme @Dependant (prototype), @RequestScoped, @SessionScoped, et même @conversationScoped pour JSF par exemple. Il y’a aussi la possibilité pour définir ses propores scopes.

Une autre fonctionnalité impressionnante des WebBeans est les producers. Si on annote une méthode un retourne un Objet de type X par @Produces, alors il devient possible d’injecter le résultat d’une telle méthode dans un autre bean, comme si c’etait défini en tant que composant à part entière.

Exemple:

@Produces @SessionScoped
public User getConnectedUser() {
  ....
}

Ensuite, dans un autre compsoant:

@Current User user.

Alors le conteneur va appeler la méthode getUser et injecter son résultat dans user.

Voilà, c’etait une présentation rapide des principales fonctionnalités de la proposition WebBeans/JSR 299.

Presque tout serait rechargeable à chaud, des managed beans jusqu’au renderers et listeners, en passant par les validators/converters et même les composants.

Autre point: il est fortement conseillé d’utiliser FAcelets comme technologie de présentation (y’en a déjà qui font du JSF avec JSP ???), car il n’y a pas de rechargement à chaud pour les TagHandlers du JSP ou encore des TLDs.

La mise en place de ceci se présente comme suit:

1. Inclure groovy-1.5.5-all.jar dans son classpath
2. Ajouter ceci à son web.xml:
   

   
   <context-param> 
   
       <param-name>com.sun.faces.developmentMode</param-name> 
   
       <param-value>true</param-value> 
   
   </context-param> 
   
   <filter> 
   
       <filter-name>GroovyFilter</filter-name> 
   
       <filter-class>com.sun.faces.scripting.GroovySupportFilter</filter-class> 
   
   </filter> 
   
   <filter-mapping> 
   
        <filter-name>GroovyFilter</filter-name> 
   
        <url-pattern>/*</url-pattern> 
   
        <dispatcher>REQUEST</dispatcher> 
   
        <dispatcher>FORWARD</dispatcher> 
   
        <dispatcher>INCLUDE</dispatcher> 
   
        <dispatcher>ERROR</dispatcher> 
   
   </filter-mapping>
   
   

   (En gros, un context-param et un filtre + son mapping)

3. Créer un répertoire « groovy » dans WEB-INF dans lequel placer les fichiers .groovy.

Notez que lorsqu’on référence les beans Groovy dans faces-config, il faut ajouter l’extension .groovy au nom qualifié.

Notez enfin qu’il s’agit encore d’une fonctionnalité encore à son inception, et que c’est loin d’être solide/fiable.