Comment partager la bibliothèque log4j le plus efficacement possible

Question

i ont quelques applications de ligne de commande java batch qui devrait être déployé comme:

batch_apps 
    app_1 
    batch1.jar 
    run_batch1.sh 
    app_2 
    batch2.jar 
    run_batch3.sh 
{...etc...} 

ce qui serait la meilleure pratique sur l'organisation d'un pool de bibliothèque partagée - par exemple log4j:

batch_apps 
    app_1 
    batch1.jar 
    run_batch1.sh 
    app_2 
    batch2.jar 
    run_batch3.sh 
    libs 
    log4j.jar 
    ojdbc.jar 

?

et d'inclure chaque fichier log4j.xml dans le propre fichier jar de chaque application? Je comprends que je voudrais besoin d'ajouter « libs » au classpath soit dans ou manifeste run_batchX.sh (quelle manière est préférable?)

Je me demandais surtout quelle serait la configuration la plus efficace en terme de performance.

grâce

Answer 1

Avoir un répertoire partagé libs à la racine de votre répertoire d'installation est certainement le chemin à parcourir. Comme les libs seront chargées une seule fois en mémoire, lorsque la JVM sera lancée, il n'y aura pas d'impact sur les performances quelle que soit la solution choisie.

Je ne mettrais pas le classpath dans les fichiers jar, car cela vous forcerait à changer vos jars si vous deviez déplacer votre répertoire lib. L'édition d'un script est beaucoup plus simple.

Je ne voudrais pas inclure le fichier conf de log4j dans vos fichiers jar, pour la même raison.

Answer 2

Cela ne répond pas directement à votre question, mais j'ai déjà essayé l'approche que vous proposez mais je vais maintenant créer un seul pot par application (voir comment le faire with Ant). De cette façon, pas besoin d'inclure quoi que ce soit dans le chemin de classe:

java -jar myApp.jar 

est tout ce dont vous avez besoin. Je trouve ça plus propre mais tout est discutable.

Cela ne fait aucune différence du point de vue des performances car chaque application est exécutée dans sa propre JVM.

Le seul inconvénient est que certaines bibliothèques seront présentes dans chaque fichier JAR. Il ne coûte plus cher de stocker sur le HD, mais ces jours-ci, MB sont assez bon marché :-) Je trade la simplicité (pas de dossier lib externe) et aucun pot jar (ne pas placer vos pots dans le dossier Java ext) sur le prix de stockage à tout moment . Si votre application ne comprend pas terrabyte de bibliothèques, je pense que c'est bien.

Pour le fichier de configuration Log4j, je placerais un fichier par défaut à l'intérieur du pot, mais fournir un fichier de configuration de l'échantillon (log4j-custom.xml.sample) que quelqu'un peut modifier et spécifier dans la ligne de commande:

java -Dlog4j.configuration=log4j-custom.xml -jar myApp.jar 

Answer 3

Vous pouvez utiliser la java Placez-les dans JAVA_HOME/lib/ext et ils seront accessibles à toutes les applications Bien sûr, cela ne sera peut-être pas le meilleur pour tous les déploiements, mais c'est certainement plus facile

Answer 4

Il semble que vos applications ne partagent pas une seule instance JVM (c.-à-d. qu'ils sont démarrés individuellement via 'java -jar batch1.jar' ou une autre.) e, le partage des fichiers .jar de la bibliothèque ne vous permet d'économiser de l'espace disque que de la RAM.

Si les applications ne partagent pas une seule machine virtuelle Java, la facilité de déploiement devrait prévaloir sur l'espace disque. Dans ce cas, je recommande de rendre chaque application autonome, soit dans un seul fichier .jar contenant toutes ses bibliothèques, soit dans un seul dossier de .jar. des dossiers. (Par exemple, placez les bibliothèques pour chaque application dans un dossier pour cette application.)

Si les applications partageaient une seule machine virtuelle Java, je recommanderais l'option de dossier de bibliothèque partagée.