J'ai un problème de conflit entre 2 versions de jar différentes.
Je dois intégrer dans un programme, sous une même jvm, une librairie java
qui utilise une version ancienne de log4j et le programme lui-même qui
utilise une version plus récente.
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre ne
peut initialiser correctement son log4j. Je n'ai bien entendu pas le choix,
ni du côté de la lib, ni dans mon programme (qui n'est pas que le mien).
J'aimerais avoir la confirmation qu'il n'est pas possible de spécifier un
paramètre quelconque dans la commande de lancement pour que chacun des
éléments puisse utiliser son propre log4j.
Sinon, quelle pourrait être la solution la moin coûteuse en temps?
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
Jean-Christophe Garnier
Bonjour, Si vous maîtrisez suffisamment les jar importés pour décider ceux que vous utilisez, vous pouvez toujours ne garder que la version la plus récente de log4j. Elle devrait être compatible avec l'utilisation que la librairie en fait. JC
Hello tout le monde,
J'ai un problème de conflit entre 2 versions de jar différentes.
Je dois intégrer dans un programme, sous une même jvm, une librairie java qui utilise une version ancienne de log4j et le programme lui-même qui utilise une version plus récente. Evidemment, lors du lancement de mon application, soit l'un, soit l'autre ne peut initialiser correctement son log4j. Je n'ai bien entendu pas le choix, ni du côté de la lib, ni dans mon programme (qui n'est pas que le mien).
J'aimerais avoir la confirmation qu'il n'est pas possible de spécifier un paramètre quelconque dans la commande de lancement pour que chacun des éléments puisse utiliser son propre log4j.
Sinon, quelle pourrait être la solution la moin coûteuse en temps?
Merci d'avance pour vos réponses.
Adobex
Bonjour,
Si vous maîtrisez suffisamment les jar importés pour décider ceux que
vous utilisez, vous pouvez toujours ne garder que la version la plus
récente de log4j. Elle devrait être compatible avec l'utilisation que la
librairie en fait.
JC
Hello tout le monde,
J'ai un problème de conflit entre 2 versions de jar différentes.
Je dois intégrer dans un programme, sous une même jvm, une librairie java
qui utilise une version ancienne de log4j et le programme lui-même qui
utilise une version plus récente.
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre ne
peut initialiser correctement son log4j. Je n'ai bien entendu pas le choix,
ni du côté de la lib, ni dans mon programme (qui n'est pas que le mien).
J'aimerais avoir la confirmation qu'il n'est pas possible de spécifier un
paramètre quelconque dans la commande de lancement pour que chacun des
éléments puisse utiliser son propre log4j.
Sinon, quelle pourrait être la solution la moin coûteuse en temps?
Bonjour, Si vous maîtrisez suffisamment les jar importés pour décider ceux que vous utilisez, vous pouvez toujours ne garder que la version la plus récente de log4j. Elle devrait être compatible avec l'utilisation que la librairie en fait. JC
Hello tout le monde,
J'ai un problème de conflit entre 2 versions de jar différentes.
Je dois intégrer dans un programme, sous une même jvm, une librairie java qui utilise une version ancienne de log4j et le programme lui-même qui utilise une version plus récente. Evidemment, lors du lancement de mon application, soit l'un, soit l'autre ne peut initialiser correctement son log4j. Je n'ai bien entendu pas le choix, ni du côté de la lib, ni dans mon programme (qui n'est pas que le mien).
J'aimerais avoir la confirmation qu'il n'est pas possible de spécifier un paramètre quelconque dans la commande de lancement pour que chacun des éléments puisse utiliser son propre log4j.
Sinon, quelle pourrait être la solution la moin coûteuse en temps?
Merci d'avance pour vos réponses.
Adobex
Adobex
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre
ne
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Adobex
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser log4j, soit c'est le programme qui la contient qui ne peut pas le faire. Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en 3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va être ignorée car c'est la première qui est prise en compte (les packages étant trop semblables)... ensuite s'en découle des incohérences quant aux classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de faire tourner le programme dans une jvm et la lib dans une autre, en permettant une communication entre les 2 par un mécanisme approprié... donc s'il n'y a pas de paramétrage possible lors du lancement de l'application, pour indiquer quel log4j utiliser pour le programme et quelle autre pour la lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" a écrit dans le message de news:40fc49ec$0$29367$
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le
monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de
log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser
log4j, soit c'est le programme qui la contient qui ne peut pas le faire.
Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en
3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va
être ignorée car c'est la première qui est prise en compte (les packages
étant trop semblables)... ensuite s'en découle des incohérences quant aux
classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de
faire tourner le programme dans une jvm et la lib dans une autre, en
permettant une communication entre les 2 par un mécanisme approprié... donc
s'il n'y a pas de paramétrage possible lors du lancement de l'application,
pour indiquer quel log4j utiliser pour le programme et quelle autre pour la
lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" <msetjc.garnier-sanspam@free.fr> a écrit dans le
message de news:40fc49ec$0$29367$626a14ce@news.free.fr...
Evidemment, lors du lancement de mon application, soit l'un, soit
l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser log4j, soit c'est le programme qui la contient qui ne peut pas le faire. Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en 3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va être ignorée car c'est la première qui est prise en compte (les packages étant trop semblables)... ensuite s'en découle des incohérences quant aux classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de faire tourner le programme dans une jvm et la lib dans une autre, en permettant une communication entre les 2 par un mécanisme approprié... donc s'il n'y a pas de paramétrage possible lors du lancement de l'application, pour indiquer quel log4j utiliser pour le programme et quelle autre pour la lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" a écrit dans le message de news:40fc49ec$0$29367$
Evidemment, lors du lancement de mon application, soit l'un, soit l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
jlp
Adobex wrote:
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser log4j, soit c'est le programme qui la contient qui ne peut pas le faire. Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en 3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va être ignorée car c'est la première qui est prise en compte (les packages étant trop semblables)... ensuite s'en découle des incohérences quant aux classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de faire tourner le programme dans une jvm et la lib dans une autre, en permettant une communication entre les 2 par un mécanisme approprié... donc s'il n'y a pas de paramétrage possible lors du lancement de l'application, pour indiquer quel log4j utiliser pour le programme et quelle autre pour la lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" a écrit dans le message de news:40fc49ec$0$29367$
Evidemment, lors du lancement de mon application, soit l'un, soit
l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Voir du coté de "endorsed mecanism" sur site sun si cela ne peut pas
résoudre ton pb.
Adobex wrote:
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le
monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de
log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser
log4j, soit c'est le programme qui la contient qui ne peut pas le faire.
Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en
3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va
être ignorée car c'est la première qui est prise en compte (les packages
étant trop semblables)... ensuite s'en découle des incohérences quant aux
classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de
faire tourner le programme dans une jvm et la lib dans une autre, en
permettant une communication entre les 2 par un mécanisme approprié... donc
s'il n'y a pas de paramétrage possible lors du lancement de l'application,
pour indiquer quel log4j utiliser pour le programme et quelle autre pour la
lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" <msetjc.garnier-sanspam@free.fr> a écrit dans le
message de news:40fc49ec$0$29367$626a14ce@news.free.fr...
Evidemment, lors du lancement de mon application, soit l'un, soit
l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Voir du coté de "endorsed mecanism" sur site sun si cela ne peut pas
Bon c'est clair pour moi mais ça ne l'est pas forcément pour tout le monde...
Alors, dans mon classpath, si je fais référence à une des 2 versions de log4j seulement, soit la lib dont j'ai besoin ne parvient pas à utiliser log4j, soit c'est le programme qui la contient qui ne peut pas le faire. Parce qu'effectivement, une des 2 versions de log4j est en 1.x et l'autre en 3.x.
Si je fais référence aux 2 versions dans mon classpath, forcément une va être ignorée car c'est la première qui est prise en compte (les packages étant trop semblables)... ensuite s'en découle des incohérences quant aux classes et méthodes qui composent les différentes versions.
J'espère avoir été plus compréhensible.
Peut-être me trompe-je mais pour moi, il n'y a pas d'autre solution que de faire tourner le programme dans une jvm et la lib dans une autre, en permettant une communication entre les 2 par un mécanisme approprié... donc s'il n'y a pas de paramétrage possible lors du lancement de l'application, pour indiquer quel log4j utiliser pour le programme et quelle autre pour la lib, c'est ce que je ferai.
Voilà, voilà...
Qui a une idée de génie?
"Jean-Christophe Garnier" a écrit dans le message de news:40fc49ec$0$29367$
Evidemment, lors du lancement de mon application, soit l'un, soit
l'autre
ne
peut initialiser correctement son log4j.
Ca ne fonctionne pas....
Qu'est-ce qui ne fonctionne pas ? Bon, je sais il se fait tard...
Voir du coté de "endorsed mecanism" sur site sun si cela ne peut pas
