Discussion :

[deutschy]

Bonjour à tous,

Dans le cadre du développement de nouveaux projets, nous avons décidé d'externaliser les configurations applicatives, dont le fichier log4j.xml.
Les librairies sont également externalisée au niveau du serveur. Chaque war d'une application embarque alors un nombre restreint de librairie.
Les applications sont déployées sur un serveur tomcat7

Le contexte étant posé, voici mon problème:
Une fois les applications déployés, il semble que log4j pose problème. En effet, aucun log n'est écrit dans le bon fichier, et en console Log4j renvoie l'erreur log4j:ERROR Attempted to append to closed appender named [FILE].
Indépendamment, chaque application fonctionne parfaitement et le problème apparaît à partir de 2 applis sur le serveur.

Les fichiers log4j de chaque application étant sensiblement identiques, j'ai commencé par renommer les appenders afin qu'aucun ne porte le même nom, mais le problème a persisté.

Au niveau de la configuration spring (les valeurs ${common_rep}/${appliName.rep} sont correctement remplacées):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
	<!-- log4j config -->
	<bean id="log4jConfigurerReturnTicket"
		class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
		<property name="targetClass">
			<value>org.springframework.util.Log4jConfigurer</value>
		</property>
		<property name="targetMethod">
			<value>initLogging</value>
		</property>
		<property name="arguments">
			<list>
				<value>file:///${common_rep}/${appliName.rep}/log4j.xml</value>
			</list>
		</property>
	</bean>

La seule façon de faire en sorte que tout fonctionne parfaitement est de ré-internaliser les librairies.
N'y a-t-il pas une solution?

A l'avance merci pour votre aide.

[tchize_]

Chaque war doit avoir sont set de librairies log4j embarqué. Sinon tu aura une configuration globale de log4j, partagée entre toutes tes applications. Dès que tu fais remonter des librairie dans le partie commune du classloader de tomcat, tu change le comportement de tomcat et tes applications ne sont plus indépendantes, ce qui va probablement t'amener pas mal de soucis. On ne peux pas faire remonter comme ça au petit bonheur la chance des librairies vers le tronc commun et ça n'a que peu d'intérêt. Ca ne fait qu'ajouter des emmerdes en production et ça fait chier les DEV car ils ne peuvent plus faire la moindre mise à jour sans affecter tous les autres applicatifs.

[jdevbe]

Le logging est un service offert par l'appserver donc pourquoi réinventer la roue ?
Il me semble que, dans Tomcat si l'on veux utiliser log4j, il y lieu de remplacer le service de logging par défaut JULI.

Attention que d'embarquer des libs utilisées par les services de l'appserver n'est pas façile à gérer et n'apporte aucune plus-value même si c'est pour obtenir des fonctionnalités uniquement disponible dans une version supérieur que celle pas défaut.
Vous risquez des erreur difficile à détecter comme une classe chargée par le classloader global utilisée par un webapp qui va dépendre d'une classe chargée par le classloader d'une autre webapp...

[deutschy]

Merci pour vos réponses,
Je vais donc revoir ma politique de gestion des librairies