sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sdx-users] Installation SDX sur Winnt4.0


From: Pierrick Brihaye
Subject: Re: [sdx-users] Installation SDX sur Winnt4.0
Date: Fri, 24 May 2002 00:29:29 +0200

----- Message d'origine ----- 
De : "Pierrick Brihaye" <address@hidden>
À : <address@hidden>
Envoyé : mercredi 22 mai 2002 09:06
Objet : Re: [sdx-users] Installation SDX sur Winnt4.0


>J'ai effectivement réussi à reproduire le problème... sans pouvoir non 
>plus le résoudre. Cependant, le message d'erreur induit peut-être 
>lui-même en erreur car si je  supprime cocoon.properties, j'ai une NPE 
>alors que si WEB-INF/cocoon.properties est bien présent, j'obtiens une 
>exception de lecture de flux, ce qui semblerait indiquer que le 
>processus va (un peu) plus loin.

Bon, l'enquête avance... Je suis allé rechercher Cocoon 1.8 dans un cvs pour 
tracer la méthode init qui semble poser problème. Je me suis aperçu que l'URL 
du fichier de configuration était résolue de la façon suivante :

jndi://localhost/sdxWEB-INF/cocoon.properties.

Donc, en ajoutant un slash devant, ce fichier est lu ;-)

Apparemment, ce protocole est mis en oeuvre dans la phase de démarrage alors 
que le port n'est pas encore ouvert (d'où l'absence du 8080)... je vais suivre 
ça ; c'est une nouveauté de Tomcat 4.

Ensuite... je n'avais pas tout à fait tort :

>Je pense donc que c'est la lecture du *contenu* de cocoon.properties et, 
>  peut-être, la résolution de l'URL du cocoon_repository. Est-ce que 
>Tomcat 4.0, à cause d'une mécanisme de sécurité que j'ignore, 
>n'interdirait pas la création de ce fichier ?

Il y a manifestement également un problème dans le chargement des jar car, le 
javax.xml.transform.Source contenu dans aa3_saxon n'est pas detecté. Je me suis 
également renseigné, et j'ai mis les lib de sdx dans tomcat/lib pour être sûr 
qu'elle soient chargées en premier. Ceci dit, même les développeurs de Tomcat 
ne sont pas fichus de dire dans quel ordre elles le sont, au moins au vu de 
l'info que j'ai trouvée.

J'en suis au point où Cocoon n'arrive pas à lire la ressource
resource://org/apache/cocoon/processor/xsp/library/java/util.xsl

C'est bizarre car les précédentes, auxquelles on accède par le même protocole, 
sont lues (ou interprétées ?)... Je pense donc qu'il y a réellement un problème 
d'accès aux classes chargées...

Bref, l'enquête continue...

p.b.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]