Discussion :

[1ereClasseTac]

Bonjour à tous,

J'ai actuellement un problème épineux avec une application Web développée sous WSAD (Web Sphere Application Developper) qui utilise Hibernate (pour la persistance), Struts pour la navigation et Tiles pour la construction des pages.

Sur l'environnement de production, une erreur survient lors de l'accès à une page:
[ServletException in:/intranet/requeteur/bodySelectionCriteresPersonnes.jsp] null'
Erreur qui ne survient pas en local.
Le plus gênant est qu'aucune erreur n'est inscrite dans la console du serveur. Bref je n'ai aucune idée quant à l'origine de l'erreur.

Si quelqu'un a une piste je suis preneur.

Merci d'avance.

Séb

[c_nvy]

Peux-tu montrer la trace complète de l'erreur ?

[1ereClasseTac]

Hey bien justement il n'y en a pas... tout ce que j'ai c'est la page html avec l'erreur dessus (les frames de navigations sont quand même bien affichées):

[c_nvy]

C'est bien dommage parce que normalement, avec la trace complète, tu pourrais au moins voir sur quelle ligne de la jsp il y a un problème.

Et tu n'as vraiment aucune erreur dans la log de WebSphere du serveur de production ?

Enfin, généralement, quand on a un problème lors du déploiement d'une application sur un serveur de production alors qu'elle fonctionne bien en local, il faut voir si par exemple, les jars que tu livres dans ton appli n'existent pas déjà sur le serveur avec une version différente.
Cela peut générer des conflits. En fait, cela dépend du mode qui a été défini pour le chargeur de classes (PARENT_LAST ou PARENT_FIRST).

C'est une piste. Je ne sais pas si c'est la bonne.
Ce qui est idiot, c'est qu'il me semble avoir eu la même erreur une fois mais je ne me souviens pas ce qui la provoquait.

[1ereClasseTac]

Merci pour cette réponse c_nvy,

Pour être plus précis, la livraison se fait par la création d'un EAR via un script Ant, l'application est ensuite mise à jour via la console WebSphere (option "mettre à jour" il me semble). De fait il ne peut pas y avoir de conflits au niveau des Jars, ceux-ci sont tous "écrasés".

Par contre j'ai cherché un peu sur le Net cette histoire de chargeur de classe, les options sont normalement accessibles dans le fichier application.XML mais le notre est plutôt laconique:

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application id="Application_ID">
	<display-name>CAPEB</display-name>
	<module id="WebModule_1081417041093">
		<web>
			<web-uri>CAPEBWeb.war</web-uri>
			<context-root>CAPEBWeb</context-root>
		</web>
	</module>
	<security-role id="SecurityRole_1108049875671">
		<description></description>
		<role-name>GESTIONFICHES</role-name>
	</security-role>
	<security-role id="SecurityRole_1108053350087">
		<description></description>
		<role-name>ACCUEIL</role-name>
	</security-role>
</application>

... je ne pense donc pas que cette piste soit la bonne.
M'enfin l'important est de participer, encore merci.

[c_nvy]

Pour être plus précis, la livraison se fait par la création d'un EAR via un script Ant, l'application est ensuite mise à jour via la console WebSphere (option "mettre à jour" il me semble). De fait il ne peut pas y avoir de conflits au niveau des Jars, ceux-ci sont tous "écrasés".

Je faisais référence à un éventuel conflit entre les jars livrés dans ton ear et les jars déjà présents sur le serveur WebSphere et ce, en dehors de ton application, comme par exemple dans le répertoire lib/ext.

Savoir quel mode a été choisi pour le chargeur de classes n'est intéressant que s'il y a bien des jars sur le serveur qui pourraient être de versions différentes de ceux que tu livres dans l'ear.

[1ereClasseTac]

Je viens de vérifier sur le serveur de Pré-Production (je n'ai pas accès au serveur de Prod) et le répertoire lib\ext est vide.
Par curiosité, je suis retourné sur la page qui plantait, et aujourd'hui elle fonctionne parfaitement. Si ce problème était lié à des conflits avec des jars, il se reproduirait systématiquement, non ?

En fouinant un peu j'ai trouvé des cas un peu similaires lié à l'utilisation de Tiles, je vais tenter de ne plus l'utiliser et faire des includes de jsp, mais ça va être lourd

[1ereClasseTac]

Histoire de mettre un terme à ce thread, voici la manipulation réalisée qui a permis de supprimer l'erreur:
Cette fameuse page contenait une "optionsCollection" avec tous les codes postaux de France (quelques milliers de lignes donc)... Nous avons restreint cette liste et le message d'erreur n'apparait plus.

Bref, si un jour ce post sert à quelqu'un =)