FacesFileNotFoundException

Bonjour la communauté,

Je fais actuellement un stage dans une boite qui a un site marchand géré par un serveur d’applications Glassfissh. Pour les composants graphiques, ils ont mis en place Primefaces.

Il y a une exception qui est levé de manière irrégulière, c’est à dire qu’il peut se passer un à deux mois sans cette exception et ensuite l’exception est levée dans les logs jusqu’à plus de 100 fois par jour. Quand l’exception est levée, le site devient infiniment lent à charger les images par exemple ou à renvoyer un résultat suite à une recherche dans le moteur de recherche.

L’exception est levée uniquement pour 2 pages, le panier “showcart.xhtml” et la page d’accueil “home.xhtml”, voici les messages qu’on voit dans les logs :

StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception

com.sun.faces.context.FacesFileNotFoundException: /index.php/showCart.xhtml Not Found in ExternalContext as a Resource

StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception

com.sun.faces.context.FacesFileNotFoundException: /index.php/home.xhtml Not Found in ExternalContext as a Resource

On peut voir index.php comme le context de l’application, mais ce n’est pas du tout le cas, on a chercher à l’aide d’une commande grep sur tout le répertoire du site et il n’y a pas une seule ligne de code, ni les fichiers xml, rien avec “index.php”, en vérité on sait pas d’où vient ce “index.php”.

Et là je sèche complètement, ce qui me gène c’est que le site peut passer des semaines sans ce problème. Donc je sais pas si quelqu’un a déjà eut ce problème avec des exceptions de type FacesFileNotFoundException ? Si oui, l’avez-vous résolu et si oui, comment ?

Encore merci !

La solution du pauvre : mettre en place des “echo” / “print” partout dans le site qui impriment dans un fichier de log la chaine de caractère en cours de construction (ainsi que la date actuelle, l’heure actuelle, le nom du fichier actuel et le numéro de la ligne de code actuelle), pour voir à quel moment le fameux index.php pointe le bout de son nez, et dans quelles circonstances.

Ne pas oublier de faire débuter chaque ligne de debug ajoutée par un commentaire du style :

afin de pouvoir supprimer toutes ces lignes facilement en ligne de commande quand la phase de debug est terminée (genre sed -i ‘s#^/* debug r3fAT4 */.*$##’ mon_fichier.txt ).

Une fois que tu auras réussi à localiser un petit peu plus précisément où se produit l’erreur, tu pourras montrer les morceaux de code susceptibles de la générer et ça sera plus facile de se faire une idée du problème.

Ce qui m’étonne c’est que on parle de «index.php» alors que tu es sur un serveur Glassfish, soit un environnement Java. Donc je me demande si ce n’est pas plutôt une requête utilisateur qui tente d’accéder a ce fichier alors qu’il n’existe pas.
Mais du coup je me demande pourquoi ton serveur devient aussi lent, l’exception est elle bien géré (try / catch / finaly) ?

Au fait comment faites vous pour retrouver un fonctionnement normal de votre serveur suite a cette erreur ? Redémarrage ?

@Branch en fait dans les logs, on voit clairement que l’exception concernant le home est levée quand l’utilisateur click sur le home, on le voit car la requête sql juste avant l’exception récupère les articles, photos etc de la page d’accueil.

Quand à l’exception qui concerne le panier, on voit dans les logs qu’elle est levée après une requête sql qui va chercher dans la base les article que le client a saisit.

C’est vrai que ça j’avais oublié de le mentionner, pardon Branch :confused:

@Mimoza, en fait index.php est ici mentionné comme le contexte du site et pas comme une page web, quant aux requêtes erronées des clients, elles sont bien gérées par l’erreur 404.

Et pour le try/catch, c’est la méthode service() de la servlet qui lève l’exception, sauf que nous n’avons pas une seule servlet, je pense qu’il s’agit d’une servlet interne au framework jsf mais sans conviction par contre… :unamused:

Et pour répondre à ta question Mimoza, on a souvent des clients qui appelle pour se plaindre que ça a planté, en fait c’est la session du client qui plante mais quand un autre utilisateur se connecte, il a une autre session propre.

En tous cas merci à vous !!

Donc, si tu sais à peu près dans quel endroit du code ça coince, tu peux appliquer la méthode du pauvre sur cette partie uniquement.

Par exemple, si ton code est :

public class Exemple { public static void main(String[] args) { int a; int b = 3; int c; a = 3 * b + 5; c = 12 * a * c + a*a; b = a + c + 3; System.out.printf("%d %d %d", a, b, c); } }

Tu le remplaces par quelque chose comme :

public class Exemple { public static void main(String[] args) { /* r3fAT4 */ System.err.printf("%d : projet/Exemple.java ligne 3 : args[1] : %s", System.currentTimeMillis(), args[1]); int a; int b = 3; int c; a = 3 * b + 5; /* r3fAT4 */ System.err.printf("%d : projet/Exemple.java ligne 8 : variable a : %d", System.currentTimeMillis(), a); c = 12 * a * c + a*a; /* r3fAT4 */ System.err.printf("%d : projet/Exemple.java ligne 10 : variable c : %d", System.currentTimeMillis(), c); b = a + c + 3; /* r3fAT4 */ System.err.printf("%d : projet/Exemple.java ligne 12 : variable b : %d", System.currentTimeMillis(), b); System.out.printf("%d %d %d", a, b, c); } }

Ensuite tu rediriges la sortie d’erreur dans un fichier de log, et quand l’erreur se présente à nouveau, tu fais un grep sur le fichier de log, puis tu inspectes le code avec l’évolution des valeurs des variables sous le coude pour détecter celles qui ne se comportent pas comme attendu.

Le problème est il reproductible sur un env de dev/int/préprod ?
Si oui mettre le serveur en débug et mettre quelques sondes pour essayer de localiser le problème.
Sinon il te reste la console JMX pour voir le comportement du serveur de la manière la moins intrusive …

Déjà merci à vous 2 de m’aider.

Alors effectivement mimoza, là on vient de mettre un glassfish tout propre, on va voir le comportement du site, comment ça se passe et est-ce que l’exception revient.

@Branch, on va voir si le problème persiste, on va mettre en place ta technique en renvoyant chaque variable dans un fichier de log, mais je sais pas, le souci semble être que quand les Beans ont été formés et que la response est prête, bah à ce moment là,la ressource web (le panier ou le home) semble ne plus être dans le contexte comme le dit le log “not found as a ressource in a external context”

En plus je comprends pas pourquoi il s’agit de “external context”

Je vous tiens au courant de toute façon, encore merci

Autre précision qui peut avoir son importance, pour reproduire cette exception, il suffit de créer un projet jsf avec netbeans par exemple, on déplace l’index.xhtml dans le WEB-INF, on exécute l’application et là on a une belle FacesFileNotFoundException.

Donc il faut déplacer une ressource web pour avoir ce genre d’exception, le truck avec ce mini projet, c’est qu’on est sûr d’avoir cette exception à 100% des cas, mais dans le cas du site marchand, un coup tout va bien et un coup les ressources web semblent volatilisées ou indiponibles ou déplacées…

Et le truck génial ici, c’est que quand ça marche pas, c’est que le framework cherche les ressources web dans un contexte qui s’appellerait “index.php”… alors que le contexte est à la racine de l’application

Là ça me dépasse par contre, est-ce qu’il y a des fichiers qui travaillent dans l’ombre et qui peuvent faire
autorité en demandant d’aller chercher un contexte particulier ?

@Mimoza, tu as parlé de sondes tout à l’heure, je comprends le concept mais est-ce qu’il y a des outils particulier pour ça ?

Encore merci à vous 2 !

Non je ne connais pas d’outil particulier pour cela, en général de simple log en debug me suffisent pour cerner le problème.

Sinon ton moyen de reproduction remonte la même erreur mais je doute que la cause soit identique.
Un autre moyen pour éviter que le serveur ne ralentisse trop est de lui créer ce qu’il réclame, donc ton fichier/répertoire php.
Sinon n’avez vous pas un Nginx/Apache en front ? Ça vient peut être de lui qui est mal configurer …

Salut !

Désolé pour mon temps de réponse.
Non il n’y a pas de soucis venant d’Apache, mais on commence à cibler la panne,
il y a un souci de configuration dans un des fichier xml, il y a un souci de balisage
et ça crée un conflit entre les fichiers.

Quand on repère la panne, je viens vous détailler concrètement le problème et la solution
si on la trouve bien sur :doh:

Encore merci

Bonjour,

Je viens faire un petit up, à priori il s’agirait d’un problème lié à glassfish,
on a redémarré le serveur, ça va mieux, donc est-ce qu’il se serait mélangé les pinceaux ?

Et un redémarrage aurait arrangé les choses, je suis pas trop convaincu mais on se laisse jusqu’en fin de semaine pour voir comment ça se passe.

S’il n’y a pas de problème, je posterai en résolu mais je reste sceptique.

Bon courage tout le monde

Si un redémarrage de ton serveur arrange les chose ce n’est pas très bon signe. Ton appli est finalement peut être hors de cause. Une mauvaise gestion du cache, un bug de la JVM, un mauvais rafraichissement des fichiers présent sur le serveur, les causes peuvent être aussi multiple que obscure :078

Bonne chance

Salut !

Tout à fait, on a pensé à ça directement : un cache du serveur, ou alors il a des fichiers de conf pas à jour, ou un bug…
En plus y a aucun index.php dans toute l’appli, donc ça vient sans doute du serveur, mais maintenant à savoir les causes exactes… c’est presque méta-physique là

Je vous tien au courant, encore merci à vous tous !

Bonjour tout le monde !

Avec le recul, depuis le redémarrage, ces exceptions ont quasi disparu mais restent en faible nombre.
Redémarrer le serveur semble être une pseudo solution mais là je maîtrise pas du tout l’erreur…

Je sais pas si je mets en résolu ou pas ? :doh:

Encore merci à vous tous

Non, si le problème persiste c’est qu’il n’est pas résolu. Et as tu essayé de refaire une installe complète de ton serveur ? Ça ne donne pas l’origine du problème mais si ça peut faire en sorte que tout rentre dans l’ordre :12