Как я могу обойти эту недопустимую иерархию загрузчика классов?

Я запускаю сервер приложений Java iPlanet, что-то в нем загружается commons-logging-1.0.4.jar.

Это нормально, пока одно из моих приложений не вызовет AuthSSLProtocolSocketFactory, который является другой библиотекой Apache, которая также использует commons-logging.

Я помещаю банку в путь к классам jvm и получаю эту ошибку:

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....

Кажется, что commons-logger не нравится, когда два экземпляра самого себя загружаются в разные загрузчики классов. Я предполагаю, что сервер приложений имеет свой собственный загрузчик классов, который загружает его в первый раз (хотя я не могу найти какую-либо конфигурацию сервера приложений, в которой он упоминается), поэтому, когда мое приложение загружает его во второй раз, оно выдает это исключение.

Я не могу изменить веб-сервер и не могу изменить библиотеку Apache. Предложения?


java logging apache classloader
person stu    schedule 06.05.2009    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Вы явно ставите журнал общих ресурсов в свой путь к классам? Вы сказали путь к классу jvm, поэтому я предполагаю, что вы указываете его в командной строке при запуске iPlanet. Это не рекомендуемый способ загрузки jar-файлов в J2EE-приложениях.

Проще всего просто позволить библиотеке Apache использовать банку журналов Commons, которая поставляется с iPlanet. Не помещайте файл commons-logging.jar в каталог WEB-INF/lib или в любой другой параметр пути к классам, и файл iPlanet должен быть выбран автоматически.

person AngerClown    schedule 26.06.2009

arrow_upward
3
arrow_downward

Взгляните на SLF4J.

Кроме того, http://www.qos.ch/logging/classloader.jsp помощь.

person grayger    schedule 06.05.2009

arrow_upward
0
arrow_downward

Не знаком с iplanet, но в WebSphere вы можете установить политику загрузки классов приложений как PARENT_LAST. Затем это загрузит все в загрузчик классов ваших приложений, прежде чем смотреть на родителя. Это должно решить проблему такого рода, если у вас есть аналогичные настройки.

Это означает, что вам придется предоставить все зависимости в вашем собственном приложении (что в любом случае является наилучшей практикой).

person Robin    schedule 06.05.2009
comment
Стратегия загрузки классов Java по умолчанию — PARENT FIRST — встроена почти во все классы Java, которые когда-либо были написаны. Эти классы были протестированы и опробованы в соответствии с этой стратегией. Однако нет гарантии, что они будут работать при любой другой стратегии загрузки классов. Переход на стратегию загрузки класса PARENT LAST почти всегда вызывает сожаление, иногда сразу, а иногда спустя месяцы разработки. Использование PARENT LAST, хотя и может решить вашу текущую проблему, скорее всего, не то, что вам нужно. - person Steven Devijver; 06.05.2009
comment
@Steven Devijver У меня не было такой проблемы, и это единственный способ заставить некоторые приложения работать в среде типа JEE. Кроме того, это единственный способ гарантировать, что вы используете те версии зависимых классов, которыми вы себя считаете. В пути к классам сервера всегда есть классы (особенно для синтаксического анализа xml), которые могут легко помешать независимости вашего собственного приложения. Что именно, по вашему мнению, потерпит неудачу в этом сценарии? Классы по-прежнему будут разрешаться, и версии, которые вы связываете с вашим приложением, будут использоваться вместо тех, которые определены где-либо еще. - person Robin; 07.05.2009