j'arrive à utiliser log4j dans une appli Java simple, c déja ça.
Mais dans ma webapp, j'arrive pas à générer un fichier log, j'comprend pas.
 
Voila comment je m'y prend pour utiliser Log4j ds ma webapp:
- Ajout de "log4j-1.2.6.jar" dans le rep "lib" de ma wen-app
- Création d'un fichier de config "log4j.xml" placé à la racine de la web-app (avant le rep WEB-INF).
Mon fichier log4j.xml :

 
- dans ma servlet (méthode init (ServletConfig config)), je configuer log4j par le code suivant :

 
Ensuite, pour logguer un message je fais exactement comme tu dis dans ta leçon.
Au final, quand je lance Tomcat, aucune exception n'est lancée (initialisation/configuration ok ?).
Quand un message est censé être loggé, tjs pas d'exception.
Ms au final, mon ldsWeb2.log n'est pas créé !!!!

Ha... petit complément : On peut être sur que le fichier log4j.xml est correctement lu (partie initialisation ok), car, si je met n'imp comme fichier log (à la place de "C:\tomcat4\logs\LdsWeb2.log" ), je me prend une exception (chemin invalide) dans la tête.

si tu fais un getResourceAsStream, il faut que le fichier soit dans ton classpath => dans WEB-ING/classes.
 
remarque : je ne sais pas comment marche le getResourceAsStream du servlet Context, mais epour le ClassLoader c'est comme ca en tout cas ...

bon, ben c'est pas ca alors ...

benou a écrit a écrit :   bon, ben c'est pas ca alors ...

 
hé non, dommage, j'aurais préféré !
Donc la question est encore la même qu'au début.
(merci qd même Benou)

ca a l'air correct. Ceci dit je mettrai l'init de log4j dans un ServletContextListener plutôt. C'est plus propre et au moins tu es sur que tout est fait au démarrage du serveur applicatif.
 
Là comme ça je ne vois pas. Tu es bien sur que tu n'as aucune exception.
 
Est ce que tu as lancé tomcat en ligne de commande pour voir (parce que l'exception si il y a un problème est balancé à la console évidemment).

J'utilise que fonction de base de mon moteur de servlet, je sais pas utiliser un servlet context listener.    
 
Sinon, oui, bien sur, je lance Tomcat en ligne de commande. J'ai la console quoi, si une exception était lancée, je la verrai. D'ailleurs lis mon post de complément du 1er post...

euh ... Bon un truc tout simple.
 
Arrete tomcat
Dans c:\Tomcat4\logs vire le fichier LdsWeb2.log
Redémarre tomcat
 
est ce qu'un fichier lds2Web.log est crée (meme vide)

 
Je peux pas effacer LdsWeb2.log puisqu'il n'a jammais été créé !
Autre chose : Quand j'utilise Tomcat construit dans l'IDE d'Idea, ça fonctionne...

bon c'est très simple. Si ton fichier n'est pas crée c'est que log4j n'a pas lancé sa configuraiton proprement. Lorsque log4j est configuré il crée les fichiers avec une taille de 0.
 
Et bon si ca marche dans IDEA. Je dirai que c'est une merde de classpath comme d'habitude. Tu as bien regardé TOUT les logs?
 
Ce qui se passe probablement c'est que tu compiles ta servlet et que ca passer car tu as log4j.jar dans ton environnement mais une fois que tu lances ta servlet il ne trouve rien et comme tu catch Exception ....

Ha, merde, j'avais pas regardé dans le log, désolé, je suis lourd (je m'accable tout seul, pas la peine d'en rajouter ! ).
Dans le log de Tomcat, g bien une exception :

...Même une 2e exception juste après :

 
Elle sont lancée au démarrage de Tomcat (initialisation de ma servlet, configuration de log4j)

El_Gringo a écrit a écrit : Ha, merde, j'avais pas regardé dans le log, désolé, je suis lourd (je m'accable tout seul, pas la peine d'en rajouter ! ).

 
Non je confirme que effectivement tu es très lourd ...
 
Mais bon je peux comprendre que regarder les logs n'est pas intuitif quand on débute. C'était mon cas qd j'étais à l'unnif.

Mais je pense pas que ça soit un pb de classpath, parce que j'ai bien mis log4j.jar (c pas le nom exact, ms on s'comprend) dans le repertoire "lib" de ma webapp. ça devrait suffir normalement, non ?

Bon, allez, c'est bon, j'ai trouvé d'ou ça venait.
En fait dans log4j.xml, pour le nom du fichier de log, je doublais pas les '\'
Et Dark, comment je fait pour utiliser le ServletContextListener plutot que le fichier log4j.xml que g créé (enfin, recopié sur ton article ! )

El_Gringo a écrit a écrit : Bon, allez, c'est bon, j'ai trouvé d'ou ça venait. En fait dans log4j.xml, pour le nom du fichier de log, je doublais pas les '\' Et Dark, comment je fait pour utiliser le ServletContextListener plutot que le fichier log4j.xml que g créé (enfin, recopié sur ton article ! )

 
Ca m'étonne ca. Normallement tu n'as pas besoin de faire ca dans un fichier XML à ma souvannce.
 
Sinon pour servletcontextListener c'est assez simple. Tu vas sur l'api servet et tu regardes cette interface
 
tu crées une classe genre
 
public class Log4JInitializator implements ServletContextListener
 
tu vas avoir deux méthodes à implémenter:
 
contextCreated -> ton serveur démarre
contextDestroyed -> ton serveur est en train de s'arrêter
 
dans contextCreated tu fous tes brols d'initialisation log4J. Ensuite tu dois enregistrer ta classe. Pour ce faire, dans ton web.xml tu dois ajouter une entrée  
 
<listener> avec le nom complet de la classe </listener> (un petit coup de google pour etre sur de la syntaxe.
 
Et voilà. Ca se fait tout seul

DarkLord a écrit a écrit :     Ca m'étonne ca. Normallement tu n'as pas besoin de faire ca dans un fichier XML à ma souvannce.   Sinon pour servletcontextListener c'est assez simple. Tu vas sur l'api servet et tu regardes cette interface   tu crées une classe genre   public class Log4JInitializator implements ServletContextListener   tu vas avoir deux méthodes à implémenter:   contextCreated -> ton serveur démarre contextDestroyed -> ton serveur est en train de s'arrêter   dans contextCreated tu fous tes brols d'initialisation log4J. Ensuite tu dois enregistrer ta classe. Pour ce faire, dans ton web.xml tu dois ajouter une entrée     <listener> avec le nom complet de la classe </listener> (un petit coup de google pour etre sur de la syntaxe.   Et voilà. Ca se fait tout seul

 
En tout cas, maintenant que g doublé les '\', ça marche.
 
Merci pour le ServletContextListener, j'vais essayer ça après manger.

Euuh, sinon, ous, avec Tomcat, on a des problèmes marrants, avec les getRessourceAsStream :
 
Si on fait ça :  

 
 
Ca marche pas!!
 
Alors que :  

 
 
Etonnant, non??

ben nan c'est normal !
 
quand tu fait le p.getClass().getResourceAsStream, il utilise le ClassLoader qui a servit à charger la classe Properties. Comme Properties doit être utilisé par tomcat, le classloader utilisé est celui du chargement de Tomcat.
 
Tomcat gère ses propres ClassLoader, ce qui lui permet d'avoir des classpath différents pour chaque web-app => dans chaque web-app, les classes qui devraont être chargées utiliseront leur propre ClassLoader
 
Si ta class Toto est une class d'une de tes web-app, elle sera chargé par le ClassLoader de la web-app. donc quand tu feras un Toto.getClass().getResourceAsStream(), c'est le classloader de cette web-app qui sera utilisé (avec le classpath vers le rep WEB-INF/classes où est ton fichier de properties).
 
Le classloader de Tomcat lui n'a pas connaissances des différentes web-app => tu ne peux pas l'utiliser pour accéder à des fichiers de propriétés d'une web-app => il ne faut pas que tu fasses le getClass() sur des objets qui ne sont pas dépendant de ta web-app => pas un des objets de la jdk.
 
La bonne technique c'est de toujour faire un this.getClass(). (ou NomDeTaClasse.class si tu est dans un contxt static). Comme ca t'es pas emmerdé.
 
autre solution, passer par le ClassLoader du currentThread, mais là je connais pas trop et ca devient vraiment compliqué ...

ouais, remarques, ça se défend...Ou alors, vu que la conf de toutes les web-apps sera commune, pour pas se faire chier, je la met dans un rep. du classpath de tomcat (enfin, je fais un lien, quoi)...Mais c'est un peu du bidouillage!

gfive a écrit a écrit : ouais, remarques, ça se défend...Ou alors, vu que la conf de toutes les web-apps sera commune, pour pas se faire chier, je la met dans un rep. du classpath de tomcat (enfin, je fais un lien, quoi)...Mais c'est un peu du bidouillage!

c'est vachement dégeu tu veux dire !!!!

Pour récupérer une ressource située dans l'arboresence de mon appli web, je préfère utiliser la méthode suivante que je trouve plus propre que getResourceAsStream():
 
Appeler la méthode getRealPath("toto.txt" ) sur une référence de ServletContext
 
Ainsi, je suis sûr que la ressource retournée est bien celle que je veux (c-à-d celle de ma webapp) car le getRealPath() recherche uniquement dans les répertoires de la webapp.
 
Si je dis ça c'est parcequ'il me semble que si tu appelles getResourceAsStream("toto.txt" ) et qu'un fichier toto.txt existe hors de l'arborescence de ta webapp, Java risque de te retourner une référence vers ce fichier !
 
Sinon, pour la configuration de log4j. Je crois qu'utiliser des slashs au lieu des anti-slashs (en séparateur de fichier) est plus portable car Java interprète les slashs même sous Windows.
 
Enfin, c'que j'en dis  

le problème de ton truc c'est que les fichiers sont en libre accès sur le site => pour des fichiers de properties c'est pas top

DarkLord a écrit a écrit :     Ca m'étonne ca. Normallement tu n'as pas besoin de faire ca dans un fichier XML à ma souvannce.   Sinon pour servletcontextListener c'est assez simple. Tu vas sur l'api servet et tu regardes cette interface   tu crées une classe genre   public class Log4JInitializator implements ServletContextListener   tu vas avoir deux méthodes à implémenter:   contextCreated -> ton serveur démarre contextDestroyed -> ton serveur est en train de s'arrêter   dans contextCreated tu fous tes brols d'initialisation log4J. Ensuite tu dois enregistrer ta classe. Pour ce faire, dans ton web.xml tu dois ajouter une entrée     <listener> avec le nom complet de la classe </listener> (un petit coup de google pour etre sur de la syntaxe.   Et voilà. Ca se fait tout seul

 
Merci Dark.
Pour info, la syntaxe exacte c'est :

ah ouais c'est l'histoire du class que j'avais oublié
 
merci...

DarkLord a écrit a écrit : ah ouais c'est l'histoire du class que j'avais oublié   merci...

 
C moi qui t'remercie, c vrai que ça fait carrément plus propre.

--greg-- a écrit a écrit :

 
c'est --greg-- qui m'a appris. Enfin je connaissais lorsque j'ai passé la certif mais avec mon employeur précédent, j'avais jamais l'occasion de mettre en pratique
 
donc --greg--

avoue que c'est ce que tu cherchais hein  
 

DarkLord a écrit a écrit : avoue que c'est ce que tu cherchais hein

perspicace

 
bah...expliques ça aux mecs qui font les mises à jour des produits chez les clients....Pour la cohérence de version, etc, is préfèrent 100 fois faire un truc dégueu mais qui leur permet d'avoir une seule occurence des fichiers de conf et d'internationalisation, et une seule occurence des classes, que une occurence par Web-app....Déjà qu'il y a plusieurs machines, imagine si en plus, tu avais 5 ou 6 lmises à jour çà faire par machine....

si ton fichier est partagé, c'est normal qu'il doit mit dans tomcat, mais dans ce cas, il faut le mettre dans le bon rep, pas n'importe où.  
C'est dans le rep classes à la racine de tomcat je crois ... (pas sûr de moi sur ce coup là)

common/classes plutot, non ?

nan, justement je croisq ue c'est ca le piège. là c'est des rep pour tomcat.
si quelqu'un peut confirmer ...

je vais deja lire le reste du topic, je te dirais ca apres

http://jakarta.apache.org/tomcat/t [...] README.txt
 
ils disent qu'il y a un rep "shared". je l'ai jamais remarqué ...

http://www.ing-steen.se:8080/tomca [...] howto.html
bon ben maintenant c'est sûr ...