Mon probl=E8me est une peu particulier dans la mesure o=F9 il concerne
plusieurs domaines mais =E9tant donn=E9 que le vrai probl=E8me semble
venir de la classe SAXBuilder de l'API JDOM je pense qu'il a sa place
dans ce forum.
J'ai donc fait un programme JAVA qui prend en entr=E9e un fichier XML et
qui va dans un premier temps parser ce fichier, puis faire des
traitements sur les donn=E9es pars=E9es avant de finalement cr=E9er un
nouveau fichier XML r=E9sultat de ce traitement.
Ce programme fonctionne tr=E8s bien dans la console. Pour l'application
que je d=E9veloppe j'ai besoin de passer par php sur un serveur Apache2
donc pour utiliser le programme JAVA.
J'ai donc dans mon programme PHP utilis=E9 la fonction system("java
monProgramme donnees.xml", $retval); qui ex=E9cute la commande pass=E9e
en param=E8tre dans un shell. J'ai bien v=E9rifi=E9 que l'utilisateur sur
lequel tourne le serveur Apache2 a les droits n=E9cessaires, et que le
CLASSPATH et le PATH soient bien configur=E9s. D'ailleurs lorsque
j'=E9x=E9cute mon programme JAVA en mode console en =E9tant loggu=E9 sous
cet utilisateur tout marche bien.
Et l=E0, bizarrement quand j'ex=E9cute le programme, il y a un probl=E8me.
Apr=E8s pas mal de temps de recherche je suis arriv=E9 =E0 isoler ce qui
emp=EAchait le programme de fonctionner et apparemment cela viendrait de
la ligne suivante dans le programme JAVA :
[CODE]
SAXBuilder sxb =3D new SAXBuilder();
[/CODE]
J'ai r=E9duit au maximum mon programme pour ne laisser plus que =E7a dans
la classe principale du programme :
[CODE]
public ParseurDOM()
{
SAXBuilder sxb =3D new SAXBuilder();
System.out.println("Test");
}
[/CODE]
En ex=E9cutant le programme JAVA depuis PHP avec =E7a dans la classe
principale, j'ai un retour d'ex=E9cution =E0 1 qui indique qu'il y a une
erreur (qui ne peut donc venir que du constructeur SAXBuilder) et
l'affichage de la ligne "Test" ne se fait pas.
En enlevant l'appel au constructeur SAXBuilder(), j'ai bien l'affichage
de la ligne "Test". Le probl=E8me se situe donc dans le constructeur
SAXBuilder().
J'ai donc =E9t=E9 voir dans les sources de JDOM dans la classe SAXBuilder
et je ne vois rien de sp=E9cial en fait. Lors de l'instanciation, il y a
juste une instanciation de la classe DefaultJDOMFactory dont le
constructeur ne fait rien !
Donc, je ne vois vraiment pas d'o=F9 =E7a peut venir =E0 ce niveau l=E0, je
pensais =E0 un probl=E8me de localisation du driver SAX utilis=E9 par
SAXBuilder mais m=EAme en changeant et en mettant dans le constructeur
SAXBuilder() un driver SAX valide : org.apache.xerces.parsers.SAXParser
par exemple (et en modifiant le classpath), le probl=E8me reste le
m=EAme.
J'ai m=EAme tent=E9 d'utiliser d'autres API du m=EAme genre comme DOM4J ou
autres mais =E7a bloque toujours au m=EAme niveau lorsque l'on cr=E9e une
instance de la classe cherchant les drivers SAX apparemment.
Quelqu'un aurait une id=E9e de ce que je peux faire ? Peut-=EAtre
modifier des options dans Apache2 (je ne vois pas trop ce que je peux
modifier de plus en fait)? Modifier un chemin d'acc=E8s ? Ou peut =EAtre
cela ne peut pas se faire et =E7a ne marchera pas ?
Et Enfin, un message d'erreur (bravo pour avoir pensé à créer les 2 classes comme ça pour récupérer l'erreur dans la seconde :), j'y aurais pas pensé !) .
C'est l'expérience qui parle... Si la définition d'une classe A (SAXBuilder) est nécessaire lors du chargement par le Classloader d'une classe B, l'erreur apparaît un cran plus haut !
Donc effectivement c'était bien un problème de classe non trouvée. Il y a donc bien une différence entre le CLASSPATH pour l'user www-data à la compilation puisque ça compile bien et le CLASSPATH disponible lors de l'exécution via la fonction PHP apparemment. Ou peut être c'est un problème de droit. www-data n'a pas le droit d'accéder au répertoire /usr/share/java/jdom.jar lors de l'exécution depuis php.
Pour la résolution, je ne sais pas... Je ne connais pas comment marche PHP et les appels de programme externe. Fais un autre post.
Pour ma culture perso... c'est quoi www-data ?
Dans tout les cas, les logs sont essentiels...
-- David Jourand
Yes, Bingo !
Yahoooooo !
Et Enfin, un message d'erreur (bravo pour avoir pensé à créer les 2
classes comme ça pour récupérer l'erreur dans la seconde :), j'y
aurais pas pensé !) .
C'est l'expérience qui parle... Si la définition d'une classe A
(SAXBuilder) est nécessaire lors du chargement par le Classloader d'une
classe B, l'erreur apparaît un cran plus haut !
Donc effectivement c'était bien un problème de classe non trouvée. Il
y a donc bien une différence entre le CLASSPATH pour l'user www-data à
la compilation puisque ça compile bien et le CLASSPATH disponible lors
de l'exécution via la fonction PHP apparemment. Ou peut être c'est un
problème de droit. www-data n'a pas le droit d'accéder au répertoire
/usr/share/java/jdom.jar lors de l'exécution depuis php.
Pour la résolution, je ne sais pas... Je ne connais pas comment marche
PHP et les appels de programme externe. Fais un autre post.
Et Enfin, un message d'erreur (bravo pour avoir pensé à créer les 2 classes comme ça pour récupérer l'erreur dans la seconde :), j'y aurais pas pensé !) .
C'est l'expérience qui parle... Si la définition d'une classe A (SAXBuilder) est nécessaire lors du chargement par le Classloader d'une classe B, l'erreur apparaît un cran plus haut !
Donc effectivement c'était bien un problème de classe non trouvée. Il y a donc bien une différence entre le CLASSPATH pour l'user www-data à la compilation puisque ça compile bien et le CLASSPATH disponible lors de l'exécution via la fonction PHP apparemment. Ou peut être c'est un problème de droit. www-data n'a pas le droit d'accéder au répertoire /usr/share/java/jdom.jar lors de l'exécution depuis php.
Pour la résolution, je ne sais pas... Je ne connais pas comment marche PHP et les appels de programme externe. Fais un autre post.
Pour ma culture perso... c'est quoi www-data ?
Dans tout les cas, les logs sont essentiels...
-- David Jourand
sylsau
Bon, je suis toujours pas arrivé à résoudre le problème ! Mais au moins je connais la cause.
www-data c'est l'utilisateur sur lequel le serveur Apache tourne. Ce qui est bizarre c'est que lorsque je me mets en utilisateur www-data en console et que je lance le programme java tout marche normalement là et le classpath est bon dans la console.
Apparemment lorsque php lance la commande : java -cp /usr/share/java/jdom.jar Test ne prend pas en compte l'option -cp puisque là aussi je spécifie le classpath. Ensuite, j'ai pensé que peut être l'utilisateur www-data n'avait pas le droit d'accéder à des fichiers se situant dans le répertoire /usr depuis Apache par exemple. J'ai donc testé en mettant jdom.jar dans le dossier /home/sylsau notamment, et cela est pareil il me donne le même message d'erreur.
Enfin voila, je continue à tester.
Bon, je suis toujours pas arrivé à résoudre le problème ! Mais au
moins je connais la cause.
www-data c'est l'utilisateur sur lequel le serveur Apache tourne. Ce
qui est bizarre c'est que lorsque je me mets en utilisateur www-data en
console et que je lance le programme java tout marche normalement là
et le classpath est bon dans la console.
Apparemment lorsque php lance la commande : java -cp
/usr/share/java/jdom.jar Test ne prend pas en compte l'option -cp
puisque là aussi je spécifie le classpath.
Ensuite, j'ai pensé que peut être l'utilisateur www-data n'avait pas
le droit d'accéder à des
fichiers se situant dans le répertoire /usr depuis Apache par exemple.
J'ai donc testé en mettant jdom.jar dans le dossier /home/sylsau
notamment, et cela est pareil il me donne le même message d'erreur.
Bon, je suis toujours pas arrivé à résoudre le problème ! Mais au moins je connais la cause.
www-data c'est l'utilisateur sur lequel le serveur Apache tourne. Ce qui est bizarre c'est que lorsque je me mets en utilisateur www-data en console et que je lance le programme java tout marche normalement là et le classpath est bon dans la console.
Apparemment lorsque php lance la commande : java -cp /usr/share/java/jdom.jar Test ne prend pas en compte l'option -cp puisque là aussi je spécifie le classpath. Ensuite, j'ai pensé que peut être l'utilisateur www-data n'avait pas le droit d'accéder à des fichiers se situant dans le répertoire /usr depuis Apache par exemple. J'ai donc testé en mettant jdom.jar dans le dossier /home/sylsau notamment, et cela est pareil il me donne le même message d'erreur.
Enfin voila, je continue à tester.
David JOURAND
Bon, je suis toujours pas arrivé à résoudre le problème ! Mais au moins je connais la cause.
Voici des pistes :
1 - Egalement trouvé sur Nexen : Dans php.ini : Nom Par défaut Modifiable Historique java.class.path NULL PHP_INI_ALL java.home NULL PHP_INI_ALL java.library.path NULL PHP_INI_ALL java.library JAVALIB PHP_INI_ALL
2 - Tu peux voir la doc PHP sur l'appel de Java : http://fr3.php.net/manual/fr/ref.java.php
3 - http://php-java-bridge.sourceforge.net/
4 - NG fr.comp.lang.php
-- David Jourand
Bon, je suis toujours pas arrivé à résoudre le problème ! Mais au
moins je connais la cause.
Voici des pistes :
1 - Egalement trouvé sur Nexen :
Dans php.ini :
Nom Par défaut Modifiable Historique
java.class.path NULL PHP_INI_ALL
java.home NULL PHP_INI_ALL
java.library.path NULL PHP_INI_ALL
java.library JAVALIB PHP_INI_ALL
2 - Tu peux voir la doc PHP sur l'appel de Java :
http://fr3.php.net/manual/fr/ref.java.php
