Dans cet article


Offres d'emploi

Tags

JSF 2 – Redirect HTTP 404 de manière programmatique

Il n’est pas forcément évident de faire un redirect 404 de manière programmatique en JAVA. 

Un des principaux cas d’utilisation est lorsqu’on utilise un url rewritting pour générer des liens vers des pages web. Il peut arriver que la page web n’existe pas ou n’existe plus mais que la redirection (par exemple avec pretty-faces) vous a déjà fait calculer une partie de la page. Il devient dès lors très compliqué d’envoyer proprement une 404 au navigateur et non pas un simple message d’erreur.

Pourquoi il est important d’envoyer une vrai error 404? 

Pour le référencement. En effet il est important que les moteurs de recherche trouvent bien une erreur 404 et non une page d’erreur classique. Sinon le référencement va en patir.

Créer une vrai erreur HTTP 404

La solution se fait en deux étapes.

Le validator

Premièrement créer un validator qui va valider la donnée « métier ». Est-ce que ma page existe réellement. 

package validators;

import java.io.IOException;

import javax.faces.context.FacesContext;
import javax.inject.Inject;
import javax.inject.Named;
import javax.servlet.http.HttpServletResponse;

@Named
public class PageValidatorFaq404 {

    public void validate(javax.faces.event.ComponentSystemEvent tete) {
      
        if (monTest) {
  
            FacesContext context = FacesContext.getCurrentInstance();
            context.getExternalContext().setResponseStatus(404);
            context.responseComplete();
            HttpServletResponse lHttpServletResponse = ((HttpServletResponse) FacesContext
                    .getCurrentInstance().getExternalContext().getResponse());
            try {
                lHttpServletResponse
                        .sendError(HttpServletResponse.SC_NOT_FOUND);
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }

}

 

Dans la JSF

Dans la page que nous voulons valider, il suffit de rajouter un validator sur la phase prerenderview comme ci.

<
f:metadata>
    <
f:event listener="#{pageValidatorGlossaire404.validate}" type="preRenderView" />
 <
/f:metadata>

 

Ainsi lors que la page ne valide pas le validator, une vrai erreur 404 est envoyé au navigateur et vous pouvez ensuite la traiter de manière propre, en affichant par exemple une jolie page 404 en la configurant de votre web.xml comme ceci:

Le web.xml

<
error-page>
        <
error-code>404<
/error-code>
        <
location>/error404.xhtml<
/location>
    <
/error-page>

L'équipe AXOPEN

Voir aussi les articles suivants

Supprimer les jsessionid dans les url et pretty faces pour le référencement
Le problème des jsessionid dans les urls Comportement des jsessionid Ceci n’est pas un bug mais le fonctionnement de base de JEE qui crée une session. Ne sachant pas si le navigateur du client possède la fonctionnalité des cookies, java préfère passer la session dans l’url. Problème pour le référencement Pour le référencement ceci peut être panélisable car ceci crée des urls peu référencable. Afin de maximiser le référencement, il est donc préférable de supprimer la variable jsessionid des url générées par le serveur.
Lire l'article

Optimisation WEB: Partie 1 – Page Speed (vitesse de la page) pour les images
Optimisation WEB: Page Speed pour les images   Afin d’optimiser votre site web (ou application web), il existe un certain nombre d’actions simple à effectuer. Dans cet article nous allons passer en revue le moyen d’optimiser la vitesse de chargement de votre page web. Pour ce faire, nous allons utiliser un outil mis à disposition par GOOGLE (pagespeed) disponible à l’adresse suivante: https://developers.google.com/speed/pagespeed/ Cet outil donne un certain nombre d’indicateur simple avec des conseils pour les réaliser.
Lire l'article

JBoss 7 et java.lang.IllegalArgumentException: null source
En développement un écran très complexe dans une de nos applications, nous avons reçu ce type d’erreur, qui nous ont – au début – parues aléatoire. Après de nombreuses recherches, surtout afin de créer un cas de test satisfaisant, nous nous sommes aperçu que le problème se posait à cause d’un trop grand nombre de paramètres POST. Voici l’anomalie qui se produit: java.lang.IllegalArgumentException: null source at java.util.EventObject.<init>(Unknown Source) at javax.faces.event.SystemEvent.<init>(SystemEvent.java:71) at javax.
Lire l'article