#java #classloader #jetty-9 #contextclassloader
Вопрос:
Я столкнулся с проблемой загрузки файлов ресурсов внутри веб-приложения из версии Jetty 9.4.37.v20210219 .
Я делаю Thread.currentThread().getContextClassLoader() это, чтобы получить экземпляр загрузчика классов, а затем пытаюсь получить ресурс в виде потока classLoader.getResourceAsStream("resourceFileName") . Эта строка кода возвращает значение null из версии jetty 9.4.37.v20210219 .
При проведении сравнительного исследования путем регистрации экземпляра загрузчика классов в версиях jetty 9.4.37.v20210219 и 9.4.36.v20210114 , я вижу разницу ниже
На пристани 9.4.37.v20210219 я получаю
startJarLoader@1c4af82c
но с пристанью 9.4.36.v20210114 я получаю
WebAppClassLoader{984235065}@3aaa3c39
Указывает ли startJarLoader путь к классу сервера jetty? Каков стандартный способ загрузки файлов ресурсов из веб-приложения?
Дополнительная информация, мое веб-приложение развернуто, JETTY_BASE/webapps и у меня есть файл ресурсов, который я пытаюсь загрузить в него. Это веб-приложение имеет банку зависимостей, в которой развернута JETTY_BASE/lib/ext . Thread.currentThread().getContextClassLoader() используется в методе внутри веб-приложения, который вызывается из его jar-файла зависимостей. Другими словами, вызываемый поток принадлежит банку зависимостей веб-приложения и находится в пути к классу сервера/загрузчике родительского класса. Это причина, по которой я предполагаю, но я хотел бы знать, почему эта разница видна в версиях jetty 9.4.37.v20210219 и выше.
Кстати, выполняя MyClass.class.getClassLoader() возврат WebAppClassLoader{984235065}@3aaa3c39 , я мог бы получить ресурс в виде потока, используя то же classLoader.getResourceAsStream("resourceFileName") самое, но я хотел бы знать, почему существует разница в поведении с версией jetty 9.4.37.v20210219 .
Ценю любую помощь! Заранее спасибо!