Comment contourner cette hiérarchie de chargeur de classe non valide?

Je lance le serveur d'applications Java d'iPlanet, quelque chose charge commons-logging-1.0.4.jar.Comment contourner cette hiérarchie de chargeur de classe non valide?

Très bien jusqu'à ce qu'une de mes applications appelle AuthSSLProtocolSocketFactory qui est une autre bibliothèque apache qui utilise également commons-logging.

je mets le pot sur le chemin de classe jvm et obtenir cette erreur:

Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy....

Il semble que commons-logger n'aime pas avoir deux instances de lui-même chargés dans différentes classloaders. Je suppose que le serveur d'applications a son propre chargeur de classe qui le charge la première fois (bien que je ne trouve aucune configuration de serveur d'applications qui le mentionne), alors quand mon application va le charger une seconde fois, il lève cette exception.

Je ne peux pas changer le serveur Web, et je ne peux pas changer la bibliothèque apache. Suggestions?

Source

2009-05-06 stu

Est-ce que vous mettez explicitement des communs dans votre classpath? Vous avez dit jvm classpath, donc je suppose que vous le spécifiez sur la ligne de commande lorsque vous démarrez iPlanet. Ce n'est pas la méthode recommandée pour charger des fichiers JAR dans les applications J2EE. Le plus simple est de laisser la bibliothèque Apache utiliser le jar de journalisation des communs fourni avec iPlanet. Ne placez pas commons-logging.jar dans votre répertoire WEB-INF/lib ou dans n'importe quel paramètre de chemin de classe et l'iPlanet doit être automatiquement sélectionné.

Source

2009-06-26 14:01:37 AngerClown

Jetez un coup d'œil à SLF4J. En outre, http://www.qos.ch/logging/classloader.jsp aidera.

Source

2009-05-06 14:55:43 grayger

Je ne suis pas familier avec iplanet, mais dans WebSphere, vous pouvez définir PARENT_LAST comme stratégie de chargement de classe. Cela chargera alors tout dans votre classloader d'applications avant de regarder le parent. Cela devrait résoudre ce genre de problème, en supposant que vous ayez un paramètre similaire. Cela signifie que vous devrez fournir toutes les dépendances dans votre propre application (ce qui est la meilleure pratique de toute façon).

Source

2009-05-06 17:09:01 Robin

La stratégie de chargement des classes Java par défaut, PARENT FIRST, est intégrée dans presque toutes les classes Java qui ont déjà été écrites. Ces classes ont été testées et essayées dans le cadre de cette stratégie. Il n'y a cependant aucune garantie qu'ils travailleront dans le cadre d'une autre stratégie de chargement de classe. Passer à une stratégie de chargement PARENT LAST classe est presque toujours quelque chose que vous allez regretter, parfois tout de suite, quelque chose après des mois de développement. L'utilisation de PARENT LAST - bien qu'elle puisse résoudre votre problème actuel - n'est probablement pas ce que vous voulez. –

@Steven Devijver Je n'ai pas eu ce genre de problème, et c'est le seul moyen de faire fonctionner certaines applications dans un environnement de type JEE. C'est aussi le seul moyen de garantir que vous utilisez les versions de classes dépendantes que vous pensez être. Il y a toujours des classes sur le classpath des serveurs (en particulier pour l'analyse XML) qui peuvent facilement interférer avec l'indépendance de votre propre application. Quel est exactement ce que vous pensez échouer dans ce scénario? Les classes seront toujours résolues, et les versions que vous regroupez avec votre application sont utilisées à la place de celles définies ailleurs. – Robin

Comment contourner cette hiérarchie de chargeur de classe non valide?

Répondre

Questions connexes