| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Вопрос по загрузке классов |
| Автор: Alexandr87 22.9.2010, 12:02 |
| Ситуация такая. Приложение использует стороннюю библиотеку в виде .jar файла. Данная библиотека имеет функцию, которая загружает и работает с классом, имя которого я ей передал параметром. Всё работает замечательно кроме одного случая. Эта библиотека ставится другим софтом в lib/ext. И теперь библиотека из lib/ext не может найти мой класс, который я ей передаю как параметр в функцию. Удалить эту библиотеку из lib/ext и пользоваться своей копией нельзя. Что можно предпринять? |
| Автор: le_chat 22.9.2010, 20:04 |
| Если класс есть в -classpath, то в общем случае он будет найден. Нет никакой разницы, где лежит библиотека, если она подгружает классы стандартным образом. Так как это утверждение не работает, то предположу, что библиотека некорректно грузит переданный ей класс. Тогда нужно выяснить, в чем косяк библиотеки. Например, она может не использовать -classpath, а искать класс по некоторому, известному только ей пути. |
| Автор: LSD 22.9.2010, 20:04 | ||
А загрузить еще одну копию своим класслоадером можно? Поже что причина в том, что раз библиотека загружена системным класслоадером, то им же и пытается грузить указанный класс. Ну а системному класслоадеру понятное дело, начхать на класпас. |
| Автор: Старовъръ 22.9.2010, 21:59 | ||
|
| Автор: Alexandr87 24.9.2010, 07:04 | ||||
Разница есть. Jar`ики, которые лежат в lib/ext подгружаются системным класслоадером, который ищет классы только в lib/ext. Когда происходит загрузка нового класса из существующего, по-умолчанию используется тот-же класслодер, которым был загружен текущий класс. Отсюда он не может найти классы вне lib/ext.
Неплохой вариант. Но пока решилось патчингом библиотеки из lib/ext (открытая библиотека), чтобы она использовала более низкий класслоадер при загрузке классов. |
| Автор: le_chat 25.9.2010, 20:25 |
вопрос меня заинтересовал и я провел некоторый инвестигейшн  вот что удалось выяснить: 1) системные класс грузятся BOOTSTRAP загрузчиком. Он же загружает библиотеки расширений из JAVA_HOME/lib/ext. Он не видит классы, указанные в -cp 2) классы приложения грузятся СИСТЕМНЫМ загрузчиком. Это тот, который можно получить ClassLoader.getSystemClassLoader() Соответственно, он видит -cp 3) был найден workaround для вашего случая. Он заключается в использовании параметра java.ext.dirs. Этот параметр указывает директории, где jvm должна искать библиотеки расширений. Соответственно, его можно использовать в нескольких вариантах: - задать этот параметр пустым -Djava.ext.dirs= Тогда расширения грузится не будут (в том числе и из JAVA_HOME/lib/ext) - указать в нем стандартную директорию JAVA_HOME/lib/ext, а затем директорию, откуда библиотека должна загружать классы. для этого случая есть один нюанс: все классы должны лежать в .jar файлах, так как jvm подгружает только джары, которые лежат в этих директориях; порядок путей в параметре jvm использует так как и в -cp -слева направо. то есть первыми будут загружены библиотеки, чей путь указан левее, далее повторно классы jvm, естественно, грузить не будет. При этом, естественно, все библиотеки расширений грузятся BOOTSTRAP загрузчиком и не видят -cp Использование параметра выглядит примерно вот так: java -Djava.ext.dirs=D:\projects\testClassLoader\testClassLoader\ext;c:\Java\jdk1.6.0_21\jre\lib\ext -cp target/classes testclassloader.TestModuleMain |
| Автор: Skipy 27.9.2010, 11:57 | ||
Потенциальная проблема - расширения имеют бОльшие права, чем код, загруженный системным загрузчиком. Как бы чего не напортить. |
