Discussion :

[coucou78]

bonjour,

actuellement nous mettons à jour notre contexte via un partage samba.

or tomcat (5.0.30) ne prend pas en compte les modifications (ex. log4j.xml), il nous faut le rédammarer systèmatiquement (serveur mutualisé de dev. :-( ), avez vous une astuce ? (moins violente)

cela ne serait pas du a samba qui lorsque nous copions le fichier prends la date de création sous windows , qui est toujours ultérieur au fichier utilisé par tomcat

merci d'avance

[tchize_]

Je connais pas ta config, mais par défaut, autant que je sache, tomcat ne prend pas en comptes les modifications des fichier (reloadable=false), a moins que tu l'ai explicitement demandé. Ce n'est d'ailleurs pas recommandé en production en raison de la perte de performance (chaque requete qui arrive au serveur entraine un code de check du filesystem). De plus, le reloadable ne check que les fichiers dans WEB-INF/lib et WEB-INF/classes. Le meilleur moyen c'est de demander à tes users de faire un reload explicite de la webapp quand il veulent appliquer leur changement.

[coucou78]

oui ils font bien le reload via le manager (securisé tout même)
mais le fichier n'est pas pris compte du fait que sa date est perimé par rapport a celui en cours sur le tomcat.

[tchize_]

Ca ne devrais pas arriver, pour la simple raison que tomcat relit *tous* les fichiers d'une webapp lorsque celle-ci redémarre (il n'a aucune raison fonctionnelle d'en garder un cache).

Pourrais-tu préciser plusieurs points:

1) os sur lequel tourne tomcat (ne devrais pas avoir d'incidance, mais bon)
2) que se passe-t-il si tu fait un "touch" du fichier avant le reload de la webapp?
3) quels sont les fichiers qui présentent ce phénomène
4) as-tu vérifié que ce n'est pas un problème de ta couche de partage de fichier samba qui garderais un cache (lire le fichier problématique depuis le serveur pour voir si il est vraiment "à jour" ou si le problème va plus loin qu'un problème de dates.

[coucou78]

merci de repondre.

1) linux rehl 4.5
2) un touche me donne le bon resultat, le contexte redemarre ET prends bien en compte le fichier modifié
3) log4j.xml
4) gros doute ... car notre samba n'implemente pas les options dos filetime ..

je creuse

[tchize_]

où est situé ce log4j.xml? Si c'est dans le répertoire de la webapp, désolé mais le problème est en dehors de tomcat est se trouve sur ta couche fichier, tomcat ne garde pas de cache de ces fichiers. Eventuellement, essayer de purger le répertoire work/ associé à la webapp (si tu utilise lambda probe pour faire les déploiement, il a une option pour purger ce folder, sinon vas-y "à la main").

[coucou78]

tu as surement raison je pense que le problème vient des droits sur nos fichiers , surtout via la depose de ces derniers par le biais d'un share samba....

existe-il une doc. pour monter un serveur de production sous tomcat (avec droits etc ).

Car je me heurte aussi a lagestion des version car une distrib ne permet pas de gérer finement la version ds jvm et du tomcat, on prends la version, de la distrib et basta.

voila merci de tes lumieres.

[tchize_]

Le mieux c'est de télécharger la version de tomcat dont tu as besoin, directement sur le site d'apache, et pas passer par une version "bidouillée" fournie avec la distrib. Si on prend l'exemple de redhat, une partie des classe, à une époque, était recompliée avec gcj, çà rendait les stacktrace d'erreur amusant à lire, et sur le mailing list la réponse était systématiquement "tester avec un tomcat standard, si çà marche tujours pas, revenez". Télécharge aussi la jvm dont tu as besoin à la main, et, si tu veux fixer la jvm utilisée par tomcat, indique explicitement la valeur de JAVA_HOME en haut de catalina.sh
Ainsi, t'es certains à la vois de la version de la jvm et de la version de tomcat, un gain non négligeable pour tes utilisateurs. Pour ce qui est des droits d'accès au déploiement, rien n'est prévu en base dans tomcat. Faut savoir que si une webapp veux foutre la merde, elle pourra le faire, puisque tout tourne dans la même jvm. Y a bien le security context qui permet d'isoler les webapps, mais le problème est qu'il est plus contraignant qu'autres chose, et certains librairies ne fonctionneront pas avec (utilisation de l'api de reflection pour hibernate, accès au système de fichiers pour les loggers, etc). Tu peux manuellement rajouter ces droit dans le security policies, mais chaque droit est aussi une faille vis-à-vis de l'isolation totale des webapp

-> au final t'arrive quand même sur un modèle basé en partie sur la "confiance"

[coucou78]

merci tchize_

je vient d'écrire une doc. de normalisation des repertoires, plus securisation, car ca devenait le souc.

J'ai donc isolé le webapps sous un /var/tomcat/context de l'install. tomcat qui est sous /opt/jakarta-5.x.x (le server.xml appBase me permet de parametrer ca)

les user ont full accés sous leur contexte (user:user 770) mais aucun accés sous l'install tomcat.

par contre tomcat est dans le groupe du user ... (avant c'etait l'inverse chez nous user ds grp tomcat !!!!)