Page vierge en JSF

Question

Si mon code lève une exception, parfois - pas toujours - le jsf présente une page vierge. J'utilise des facelets pour la mise en page. Une erreur similaire a été signalée à ce message de Sun forumn´s , mais sans réponse. . Quelqu'un d'autre avec le même problème, ou une solution? ;)

En raison de certaines demandes. Voici plus de datails:

web.xml

 <error-page>
        <exception-type>com.company.ApplicationResourceException</exception-type>
        <location>/error.faces</location>
 </error-page>

Et la pile associée à jsf est imprimée après la véritable exception:

####<Sep 23, 2008 5:42:55 PM GMT-03:00> <Error> <HTTP> <comp141> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1222202575662> <BEA-101107> <[weblogic.servlet.internal.WebAppServletContext@6d46b9 - appName: 'ControlPanelEAR', name: 'ControlPanelWeb', context-path: '/Web'] Problem occurred while serving the error page.
javax.servlet.ServletException: viewId:/error.xhtml - View /error.xhtml could not be restored.
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
    at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:525)
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:261)
    at weblogic.servlet.internal.ForwardAction.run(ForwardAction.java:22)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(Unknown Source)
    at weblogic.servlet.internal.ErrorManager.handleException(ErrorManager.java:144)
    at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:2201)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2053)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
javax.faces.application.ViewExpiredException: viewId:/error.xhtml - View /error.xhtml could not be restored.
    at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
    at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)

J'utilise la version jsf Mojarra 1.2_09 , richfaces 3.2.1.GA et facelets 1.1.13 .

J'espère avoir de l'aide: (

Answer 1

Je pense que cela dépend en grande partie de votre mise en œuvre de JSF. J'ai entendu dire que certains rendraient les écrans vierges.

Celui que nous utilisions générerait une erreur 500 avec une trace de pile. D'autres fois, les boutons ne fonctionneraient pas sans erreur de la part de l'utilisateur. C'était tout au cours de notre phase de développement.

Mais le meilleur conseil que je puisse vous donner est de capturer les exceptions et de les consigner dans un journal des erreurs afin que vous ayez la trace de la pile pour le débogage ultérieurement. Pour les messages auxquels nous ne pouvions rien faire comme un échec de backend, nous ajouterions simplement un message fatal au FacesContext qui s'afficherait à l'écran et consignerait le suivi de la pile.

Answer 2

J'ai corrigé un problème similaire dans ma page error.jsp aujourd'hui. Ce ne sera pas exactement le même que le vôtre, mais cela pourrait amener quelqu'un dans la bonne direction s'il rencontre un problème similaire. Mon problème semblait provenir de deux sources différentes.

Tout d'abord, la propriété d'exception message n'était pas définie dans certains servlets générant des exceptions interceptées par la page d'erreur. Les servlets interceptaient et rediffusaient les exceptions à l'aide de ServletException (constructeur ThreadableCause) .

Deuxièmement, dans la page d'erreur elle-même, l'auteur d'origine avait utilisé le code de scriptlet pour analyser le message à l'aide de String.split (message, "quot ;;"); car le message était . null cela a échoué. J'obtenais une NullPointerException dans mon journal des erreurs, avec le message "Un problème est survenu lors de la publication de la page d'erreur".

Ces deux choses combinées m'ont donné une page vierge à l'URL du servlet qui lançait l'exception d'origine. J'ai résolu mon problème en fournissant mon propre message d'erreur lorsque je rétribue des exceptions dans mes servlets à l'aide de ServletException (message de chaîne, Throwable rootCause) , de sorte que le message d'erreur ne sera plus null . J'ai également réécrit la page error.jsp en utilisant EL au lieu du code de scriptlet, mais ce n'était pas strictement nécessaire.

Answer 3

Pour une page vierge sur JSF 2, placez un point d'arrêt dans ExceptionHandlerWrapper.handle ou une classe remplaçant cette méthode. Dans mon cas, cela était dû à un code personnalisé qui était trop restrictif et l’erreur n’était pas enregistrée.