Comment puis-je obtenir autour de cette invalide chargeur de classe de la hiérarchie?

- Je exécuter iPlanet du serveur d'applications Java, quelque chose est en cours de chargement commons-logging-1.0.4.jar.

C'est bien jusqu'à ce que l'une de mes applications appels AuthSSLProtocolSocketFactory qui est un autre apache bibliothèque qui utilise également commons-logging.

J'ai mis le pot sur la jvm classpath et obtiens 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é dans les différents chargeurs de classes. Je suppose que le serveur d'application a son propre classloader c'est le chargement de la première fois (Bien que je ne peux pas trouver tout de configuration du serveur d'applications que le mentionne) donc quand mon application va charger un deuxième temps, il jette cette exception.

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

OriginalL'auteur stu | 2009-05-06

  1. 0

    Allez-vous mettre commons logging dans votre classpath explicitement? Vous avez dit jvm classpath, donc je suppose que vous êtes le spécifier sur la ligne de commande lorsque vous démarrez iPlanet. Ce n'est pas la méthode recommandée pour la charge des pots en J2EE applications.

    La chose la plus facile est de les laisser Apache utilisation de la bibliothèque de l'commons logging pot qui vient avec iPlanet. Ne mettez pas commons-logging.jar dans votre WEB-INF/lib dir ou en tout paramètre de chemin de classe et la iPlanet, on devrait être repris automatiquement.

    OriginalL'auteur AngerClown

  2. 3

    Prendre un coup d'oeil à SLF4J.

    En outre, http://www.qos.ch/logging/classloader.jsp aidera.

    OriginalL'auteur grayger

  3. 0

    Pas familier avec iplanet, mais dans WebSphere, vous pouvez définir vos applications classloading politique PARENT_LAST. Cela va se charger de toutes vos applications chargeur de classe avant de regarder le parent. Cela devrait résoudre ce genre de problème, en supposant que vous avez un paramètre similaire.

    Cela signifie que vous aurez à fournir toutes les dépendances dans votre propre application (qui est la meilleure pratique de toute façon).

    La valeur par défaut de la classe Java stratégie de chargement - PARENT de PREMIER est cuit dans presque toutes les classes Java qui aient jamais été écrites. Ces classes ont été testés et jugés en vertu de cette stratégie. Il n'y a toutefois aucune garantie qu'ils vont travailler en vertu de toute autre catégorie de stratégie de chargement. La commutation d'un PARENT DERNIÈRE classe de stratégie de chargement est presque toujours quelque chose qui vous viendra à regretter, parfois, quelque chose d'après des mois de développement. À l'aide de PARENT DERNIÈRE - même si cela peut résoudre votre problème actuel est probablement pas ce que vous voulez.
    Devijver je n'ai pas eu un tel problème, et c'est le seul moyen d'obtenir des applications de travailler dans un JEE type d'environnement. C'est aussi la seule façon de garantir que vous êtes en utilisant les versions de classes dépendantes que vous pensez de vous. Il y a toujours des classes sur les serveurs classpath (en particulier pour l'analyse xml) qui peut facilement interférer avec l'indépendance de votre propre application. Qu'est-ce exactement que vous pensez qu'ils vont échouer dans ce scénario? Les Classes vont encore être résolus, et les versions que vous bundle avec votre application sont utilisés à la place de ceux définis ailleurs.

    OriginalL'auteur Robin