[TOMCAT] Déploiement de war a distance : décompression partielle ?
3 réponses
Gilles Magnier
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches
deploy &co de ant, tout ceci fonctionne à peux pres correctement à un
détail pres :
tomcat ne décompresse que les .jar et .class, rendant tout le reste
inaccessible
(en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy :
le .war est bien uploadé dans
/usr/tomcat/work/Standalone/localhost/manager/myapp.war
avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml
qui correspond bien au contenu du context.xml
j'ai alors la version décompressé du war dans
/usr/tomcat/work/Standalone/localhost/myapp
le problème étant que ce répertoire ne contient que
WEB-INF/lib/malib.jar
et qu'un sc.getServletContext().getRealPath("/")
(sc étant un ServletConfig) me retourne null
je n'ai aucun message d'erreur dans les logs sorti de ceux qui
l'expliquent que le fichier
"null/conf/log4j.properties" ne peut être ouvert. ce qui est "normal"
J'ai essayé les path relatif pour voir si tomcat allait chercher dans le
.war mais il ne
semble pas.
Si quelqu'un peut maider de ses conseils, je l'en remerci d'avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
captainpaf
Le Fri, 24 Oct 2003 11:23:44 +0200, Gilles Magnier
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible (en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy : le .war est bien uploadé dans /usr/tomcat/work/Standalone/localhost/manager/myapp.war avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml qui correspond bien au contenu du context.xml j'ai alors la version décompressé du war dans /usr/tomcat/work/Standalone/localhost/myapp
Salut,
tu devrais plutôt mettre ton war dans /usr/tomcat/webapp/myapp.war il serais alors décompressé (au prochain lancement de tomcat) dans /usr/tomcat/webapp/myapp/ avec tout qui va bien. le répertoire /usr/tomcat/work/Standalone/localhost/ est utilisé par tomcat pour la création de ses class. il y a un script build.xml livré avec tomcat tout fait pour le déploiement : http://localhost:8080/tomcat-docs/appdev/sample/build.xml. En modifiant 1 ou 2 points, il est tout à fait utilisable pour la plupart des applications.
//snip...
Le Fri, 24 Oct 2003 11:23:44 +0200, Gilles Magnier
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches
deploy &co de ant, tout ceci fonctionne à peux pres correctement à un
détail pres :
tomcat ne décompresse que les .jar et .class, rendant tout le reste
inaccessible
(en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy :
le .war est bien uploadé dans
/usr/tomcat/work/Standalone/localhost/manager/myapp.war
avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml
qui correspond bien au contenu du context.xml
j'ai alors la version décompressé du war dans
/usr/tomcat/work/Standalone/localhost/myapp
Salut,
tu devrais plutôt mettre ton war dans /usr/tomcat/webapp/myapp.war
il serais alors décompressé (au prochain lancement de tomcat) dans
/usr/tomcat/webapp/myapp/ avec tout qui va bien.
le répertoire /usr/tomcat/work/Standalone/localhost/ est utilisé par
tomcat pour la création de ses class.
il y a un script build.xml livré avec tomcat tout fait pour le
déploiement :
http://localhost:8080/tomcat-docs/appdev/sample/build.xml. En
modifiant 1 ou 2 points, il est tout à fait utilisable pour la plupart
des applications.
Le Fri, 24 Oct 2003 11:23:44 +0200, Gilles Magnier
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible (en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy : le .war est bien uploadé dans /usr/tomcat/work/Standalone/localhost/manager/myapp.war avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml qui correspond bien au contenu du context.xml j'ai alors la version décompressé du war dans /usr/tomcat/work/Standalone/localhost/myapp
Salut,
tu devrais plutôt mettre ton war dans /usr/tomcat/webapp/myapp.war il serais alors décompressé (au prochain lancement de tomcat) dans /usr/tomcat/webapp/myapp/ avec tout qui va bien. le répertoire /usr/tomcat/work/Standalone/localhost/ est utilisé par tomcat pour la création de ses class. il y a un script build.xml livré avec tomcat tout fait pour le déploiement : http://localhost:8080/tomcat-docs/appdev/sample/build.xml. En modifiant 1 ou 2 points, il est tout à fait utilisable pour la plupart des applications.
//snip...
jerome moliere
Gilles Magnier wrote:
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible (en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy : le .war est bien uploadé dans /usr/tomcat/work/Standalone/localhost/manager/myapp.war avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml qui correspond bien au contenu du context.xml j'ai alors la version décompressé du war dans /usr/tomcat/work/Standalone/localhost/myapp le problème étant que ce répertoire ne contient que WEB-INF/lib/malib.jar
et qu'un sc.getServletContext().getRealPath("/") (sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat (elle fonctionne sous Jetty)... portabilite.....:)
faire autrement et ne pas reposer sur une politique de deploiement (war decompresse ou non) pourrait prendre le probleme ala base...
Jerome
Gilles Magnier wrote:
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches
deploy &co de ant, tout ceci fonctionne à peux pres correctement à un
détail pres :
tomcat ne décompresse que les .jar et .class, rendant tout le reste
inaccessible
(en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy :
le .war est bien uploadé dans
/usr/tomcat/work/Standalone/localhost/manager/myapp.war
avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml
qui correspond bien au contenu du context.xml
j'ai alors la version décompressé du war dans
/usr/tomcat/work/Standalone/localhost/myapp
le problème étant que ce répertoire ne contient que
WEB-INF/lib/malib.jar
et qu'un sc.getServletContext().getRealPath("/")
(sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat
(elle fonctionne sous Jetty)...
portabilite.....:)
faire autrement et ne pas reposer sur une politique de deploiement (war
decompresse ou non) pourrait prendre le probleme ala base...
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible (en l'occurence un fichier de config log4j)
lorsque je fais un ant deploy : le .war est bien uploadé dans /usr/tomcat/work/Standalone/localhost/manager/myapp.war avec le xml /usr/tomcat/work/Standalone/localhost/manager/myapp.xml qui correspond bien au contenu du context.xml j'ai alors la version décompressé du war dans /usr/tomcat/work/Standalone/localhost/myapp le problème étant que ce répertoire ne contient que WEB-INF/lib/malib.jar
et qu'un sc.getServletContext().getRealPath("/") (sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat (elle fonctionne sous Jetty)... portabilite.....:)
faire autrement et ne pas reposer sur une politique de deploiement (war decompresse ou non) pourrait prendre le probleme ala base...
Jerome
Gilles Magnier
Gilles Magnier wrote:
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible [snip]
et qu'un sc.getServletContext().getRealPath("/") (sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat (elle fonctionne sous Jetty)... portabilite.....:)
Effectivement, elle ne fonctionne que si le war est décompacté, ce qui est tout à fait logique puisque sinon la valeur retournée serait l'emplacement du jar lui-même (/usr/tomcat/work/Standalone/localhost/manager/myapp.war) ce qui n'est pas un path mais un fichier.
En fait j'ai fini par touver ou était le problème.
Lors de l'utilisation de la fonction deploy du manager tomcat, ce que fait la tache deploy d'ant, c'est la fonction deploy de org.apache.catalina.servlet.ManagerServlet qui est appelée.
Cette fonction effectue les vérifications d'usage puis copie le war des données du POST dans /usr/tomcat/work/Standalone/localhost/manager/ et extrait un eventuel context.xml dans ce même répertoire en le nommant nomduwar.xml.
Puis cette fonction lance l'installation du war en appelant , et c'est la qu'est toute la subtilité de l'affaire : Si un context.xml a été trouve : deployer.install(xmlURL, warURL); sinon deployer.install(path, warURL);
dans un cas xmlURL est un objet URL pointant sur le fichiers xml recopié dans le cas suivant path est un string étant le chemin de context sans le '/' du début.
or le deployer (par défaut : org.apache.catalina.core.StandardHostDeployer) agit tres différemment selon la façon dont il est appelé (deux fonctions install différentes selon si le premier paramètre est de type URL ou de type String) : - dans le premier cas (URL) il insert dans le server.xml le contenu du xml de context tout en remplacant docBase par le chemin complet du war (/usr/tomcat/work/Standalone/localhost/manager/myapp.war) - dans le second cas (String) : si il s'agit d'un war qui n'est pas dans appBase (c'est le cas qui m'interesse) il décompresse le war dans appBase + contextPath puis lance l'application
j'en conclu que la doc de tomcat n'est pas exacte : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html#Deploy%20A%20New%20Application je cite : "Upload the web application archive (WAR) file that is specified as the request data in this HTTP PUT request, install it into the appBase directory of our corresponding virtual host, and start it on the context path specified by the path request parameter."
en l'occurence si le war contient un META-INF/context.xml ce n'est pas ce qui se produit.
Maintenant pour acceder aux fichiers contenus dans le war il suffit d'utiliser sc.getServletContext().getResource(path) ou le getResourceAsStream(path) où path est un path absolu dont la racine est celle du war.
faire autrement et ne pas reposer sur une politique de deploiement (war decompresse ou non) pourrait prendre le probleme ala base...
je suis tout a fait d'accord avec toi, mon problème est que l'acces aux fichiers change et que je ne sais pas si toute les fonctions des libs dont j'ai besoin supportent l'acces via url (Xalan/Xerces).
Au final je pense que ceci nécessite un bug report, même s'il ne s'agit pas d'un bug.
Je n'arrive pas a comprendre le pourquoi d'une telle difference de façon de faire et quoi qu'il en soit il faudrait que ce soit documenter.
En tout cas je te remerci pour ta réponse.
Gilles.
Gilles Magnier wrote:
Bonjour,
Je cherche à permettre le déploiement d'une application via les taches
deploy &co de ant, tout ceci fonctionne à peux pres correctement à un
détail pres :
tomcat ne décompresse que les .jar et .class, rendant tout le reste
inaccessible
[snip]
et qu'un sc.getServletContext().getRealPath("/")
(sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat
(elle fonctionne sous Jetty)...
portabilite.....:)
Effectivement, elle ne fonctionne que si le war est décompacté, ce qui
est tout à fait logique puisque sinon la valeur retournée serait
l'emplacement
du jar lui-même (/usr/tomcat/work/Standalone/localhost/manager/myapp.war)
ce qui n'est pas un path mais un fichier.
En fait j'ai fini par touver ou était le problème.
Lors de l'utilisation de la fonction deploy du manager tomcat, ce que
fait la tache
deploy d'ant, c'est la fonction deploy de
org.apache.catalina.servlet.ManagerServlet
qui est appelée.
Cette fonction effectue les vérifications d'usage puis copie le war des
données du POST
dans /usr/tomcat/work/Standalone/localhost/manager/ et extrait un eventuel
context.xml dans ce même répertoire en le nommant nomduwar.xml.
Puis cette fonction lance l'installation du war en appelant , et c'est
la qu'est
toute la subtilité de l'affaire :
Si un context.xml a été trouve :
deployer.install(xmlURL, warURL);
sinon
deployer.install(path, warURL);
dans un cas xmlURL est un objet URL pointant sur le fichiers xml recopié
dans le cas suivant path est un string étant le chemin de context sans
le '/'
du début.
or le deployer (par défaut : org.apache.catalina.core.StandardHostDeployer)
agit tres différemment selon la façon dont il est appelé (deux fonctions
install
différentes selon si le premier paramètre est de type URL ou de type
String) :
- dans le premier cas (URL)
il insert dans le server.xml le contenu du xml de context tout en
remplacant
docBase par le chemin complet du war
(/usr/tomcat/work/Standalone/localhost/manager/myapp.war)
- dans le second cas (String) :
si il s'agit d'un war qui n'est pas dans appBase (c'est le cas qui
m'interesse)
il décompresse le war dans appBase + contextPath puis lance l'application
j'en conclu que la doc de tomcat n'est pas exacte :
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html#Deploy%20A%20New%20Application
je cite :
"Upload the web application archive (WAR) file that is specified as the
request
data in this HTTP PUT request, install it into the appBase directory of our
corresponding virtual host, and start it on the context path specified
by the
path request parameter."
en l'occurence si le war contient un META-INF/context.xml ce n'est pas
ce qui se produit.
Maintenant pour acceder aux fichiers contenus dans le war il suffit
d'utiliser
sc.getServletContext().getResource(path)
ou le getResourceAsStream(path)
où path est un path absolu dont la racine est celle du war.
faire autrement et ne pas reposer sur une politique de deploiement (war
decompresse ou non) pourrait prendre le probleme ala base...
je suis tout a fait d'accord avec toi, mon problème est que l'acces aux
fichiers
change et que je ne sais pas si toute les fonctions des libs dont j'ai
besoin
supportent l'acces via url (Xalan/Xerces).
Au final je pense que ceci nécessite un bug report, même s'il ne s'agit pas
d'un bug.
Je n'arrive pas a comprendre le pourquoi d'une telle difference de façon
de faire
et quoi qu'il en soit il faudrait que ce soit documenter.
Je cherche à permettre le déploiement d'une application via les taches deploy &co de ant, tout ceci fonctionne à peux pres correctement à un détail pres : tomcat ne décompresse que les .jar et .class, rendant tout le reste inaccessible [snip]
et qu'un sc.getServletContext().getRealPath("/") (sc étant un ServletConfig) me retourne null
navre mais il semble connu que cette methode retourne null sous Tomcat (elle fonctionne sous Jetty)... portabilite.....:)
Effectivement, elle ne fonctionne que si le war est décompacté, ce qui est tout à fait logique puisque sinon la valeur retournée serait l'emplacement du jar lui-même (/usr/tomcat/work/Standalone/localhost/manager/myapp.war) ce qui n'est pas un path mais un fichier.
En fait j'ai fini par touver ou était le problème.
Lors de l'utilisation de la fonction deploy du manager tomcat, ce que fait la tache deploy d'ant, c'est la fonction deploy de org.apache.catalina.servlet.ManagerServlet qui est appelée.
Cette fonction effectue les vérifications d'usage puis copie le war des données du POST dans /usr/tomcat/work/Standalone/localhost/manager/ et extrait un eventuel context.xml dans ce même répertoire en le nommant nomduwar.xml.
Puis cette fonction lance l'installation du war en appelant , et c'est la qu'est toute la subtilité de l'affaire : Si un context.xml a été trouve : deployer.install(xmlURL, warURL); sinon deployer.install(path, warURL);
dans un cas xmlURL est un objet URL pointant sur le fichiers xml recopié dans le cas suivant path est un string étant le chemin de context sans le '/' du début.
or le deployer (par défaut : org.apache.catalina.core.StandardHostDeployer) agit tres différemment selon la façon dont il est appelé (deux fonctions install différentes selon si le premier paramètre est de type URL ou de type String) : - dans le premier cas (URL) il insert dans le server.xml le contenu du xml de context tout en remplacant docBase par le chemin complet du war (/usr/tomcat/work/Standalone/localhost/manager/myapp.war) - dans le second cas (String) : si il s'agit d'un war qui n'est pas dans appBase (c'est le cas qui m'interesse) il décompresse le war dans appBase + contextPath puis lance l'application
j'en conclu que la doc de tomcat n'est pas exacte : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html#Deploy%20A%20New%20Application je cite : "Upload the web application archive (WAR) file that is specified as the request data in this HTTP PUT request, install it into the appBase directory of our corresponding virtual host, and start it on the context path specified by the path request parameter."
en l'occurence si le war contient un META-INF/context.xml ce n'est pas ce qui se produit.
Maintenant pour acceder aux fichiers contenus dans le war il suffit d'utiliser sc.getServletContext().getResource(path) ou le getResourceAsStream(path) où path est un path absolu dont la racine est celle du war.
faire autrement et ne pas reposer sur une politique de deploiement (war decompresse ou non) pourrait prendre le probleme ala base...
je suis tout a fait d'accord avec toi, mon problème est que l'acces aux fichiers change et que je ne sais pas si toute les fonctions des libs dont j'ai besoin supportent l'acces via url (Xalan/Xerces).
Au final je pense que ceci nécessite un bug report, même s'il ne s'agit pas d'un bug.
Je n'arrive pas a comprendre le pourquoi d'une telle difference de façon de faire et quoi qu'il en soit il faudrait que ce soit documenter.
