Richfaces redirection de la page d'erreur avec gatein, jboss 5.1.0 ga portlet pont jars et mes erreurs

Question

Je sais qu'il y a beaucoup de questions similaires sur les mêmes sujets/similaires mais je ne pouvais pas appliquer l'une des solutions à mon problème .

Je souhaite rediriger l'utilisateur vers une page d'erreur personnalisée lorsqu'une exception est détectée lors du rendu de la page de portlet. Pourquoi l'exception est-elle levée lors du rendu de la page? C'est parce que, en arrière-plan, nous le lançons pour donner à l'utilisateur des informations utiles, conçues de cette façon et ne seront pas changées de sitôt, donc mon intention est de garder ça comme ça. Je crois qu'il serait mieux si je donne des exemples: Ceci est un portlet simple que je fournis nom d'utilisation et appuyez sur le bouton ">>" pour obtenir des informations sur cet utilisateur, dans la mise en œuvre précédente son fonctionnement bien voir la deuxième photo ..

Deuxième image:

que vous pouvez voir la mise en page est correcte "" (ce qui est la façon dont il avait l'air) l'erreur page a simplement remplacé le contenu portlet wi son propre contenu et le message d'erreur que nous n'avons pas pu obtenir d'informations sur l'utilisateur . Jusqu'ici tout va bien.

Maintenant, regardons le cas du problème: Nous avons mis à jour de jboss 4.2.3 ga ga à 5.1.0 et maintenant GateIn entre en terrain de jeu. Il y avait aussi de vieux bocaux utilisés pour créer cette vue des portlets, maintenant ils sont tous mis à niveau vers les plus récents. Tels que:

(org.richfaces.framework) Richfaces-api 3.3.3-final, 
(org.richfaces.framework) Richfaces-impl 3.3.3-final, 
(org.richfaces.framework) Richfaces-ui 3.3.3-final, 
(com.sun.faces) jsf-api 2.2.14, 
(com.sun.faces) jsf-impl 2.2.14, 
(javax-servlet) servlet-api 2.5, 
(javax-servlet) jstl 1.2 

Gatein version: 3.4 

et GateIn lui-même utilise des pots compatibles JSR168 + nous avons la version JSF 1.2 (balises sont utilisées dans cette version).

Problème: comme vous pouvez le voir le portlet que nous voulons obtenir certaines informations utilisateur est brisé et fusionné dans le portlet détaillé de domaine. qui ressemble à une soupe.

Le code qui génère ce désordre appartient également à nous. qui fonctionnait correctement une fois, mais maintenant il détruit en quelque sorte toute la mise en page.

Permettez-moi de vous montrer le code qui est rendu la vue:

public void renderView(FacesContext context, UIViewRoot viewToRender) throws java.io.IOException, javax.faces.FacesException{ 
    try { 
     super.renderView(context, viewToRender); 
    }catch(FacesException e){   

     Application application = context.getApplication(); 
     ViewHandler viewhandler = application.getViewHandler(); 
     PortletRequest request = (PortletRequest)context.getExternalContext().getRequest(); 
     PortletConfig config = (PortletConfig)request.getAttribute(PortletConstants.PORTLET_CONFIG); 
     String errorView = config.getInitParameter(PortletConstants.PORTLET_FACES_ERROR_VIEW); 

     if(errorView == null || errorView.matches("")){ 
      errorView = ProvPortletViewHandler.DEFAULT_FACES_ERROR_VIEW;      
     } 

     Throwable cause = e.getCause(); 
     FacesMessage fm= findProvisioningException(cause); 
     if(fm == null) 
     {    
      request.setAttribute("ErrorMessage", "Unknown Error occured"); 
     } 
     else 
     { 
      request.setAttribute("ErrorMessage", fm.getSummary()); 
     } 

     viewToRender = viewhandler.createView(context,errorView);   
     context.setViewRoot(viewToRender);    
     viewhandler.renderView(context, viewToRender); 

     PortletSession objSes = (PortletSession)context.getExternalContext().getSession(false); 
     objSes.invalidate(); 
    } 
} 

Dans ce morceau de code, vous pouvez voir qu'il ya super.renderView(context, viewToRender);

Il va tout le chemin aux services et fait l'appel de service. les appels de service renvoie une exception pour laquelle cet utilisateur n'a pas d'informations dans DB. et cette exception est convertie en FacesException sur la route (nous le faisons).

Le problème n'est pas son exception ni sa conversion en une exception FacesException.

Le problème se produit dans cette partie

viewToRender = viewhandler.createView(context,errorView);   
context.setViewRoot(viewToRender);    
viewhandler.renderView(context, viewToRender); 

pour autant que nous débogués. Nous pensons que l'ancienne vue rendue partiellement en raison d'une exception ne peut pas être remplacée par la vue d'erreur.

Mais que pourrait-il faire si cela fonctionnait auparavant. nous n'avons pas changé cette partie du code.

Cette information est-elle suffisante pour donner une idée du problème? Auriez-vous besoin de plus de détails? Que pensez-vous que nous faisons mal ici?

Merci & ce qui a trait

Answer 1

Après avoir regardé en profondeur, on voit que lorsque la demande vient, sa réponse est créé et rempli à ce moment. Il contient déjà du contenu HTML. Lorsque vous essayez de rediriger un nouveau fichier jsp, il ajoute de nouveaux éléments HTML à cette réponse. Ainsi, les éléments HTML à l'intérieur de la réponse deviennent obscurs pour Gate-in. Afin d'éviter ce problème, une réinitialisation de la réponse est suffisante. Cela peut être fait en réinitialisant le tampon de réponse, peut être vu sur le code;

 viewToRender = viewhandler.createView(context, errorView); 
    context.setViewRoot(viewToRender); 
    **((javax.portlet.RenderResponse) context.getExternalContext().getResponse()).resetBuffer();** 
    viewhandler.renderView(context, viewToRender);