не из ярн-класспаса, а из джарника аппликейшона? Есть что-то проще кодинга своей загрузки через URLClassloader?
Ссаное авро в 3.3 бампнули до 1.11 и в строгом соответствии с семвер изменили апи.
@xhumanoid ты наверняка знаешь)
Можно сделать релокейты нужных пакетов в maven-shade-plugin при сборке jar
помогает в случае если приложение собирается в жирный жарник, если приложение как пакет пускается подбирая зависимости из класспасса - работать не будет
Ну насколько я понимаю, в моем случае так и происходит. Класслоадер спарка хочет загрузить класс, но перед тем, как это сделать самостоятельно, просит сначала родителя попробовать это сделать. Родитель находит в своем класспасе более свежую версию и успокаивается на этом. А потом в рантайме взрывается, потому что родитель загрузил класс без нужной сигнатуры.
ну самый простой вариант если нет контроля над класспасом кластера, это собирать жирные жарки и шейдить зависимости. в жарке конфликтные пакеты просто переименовываются и класслоадер грузит другие имена
Я вот не до конца понимаю, как тут сработает шейдинг. В коде написано import org.apache.avro.Schema. Он есть в класпасе ярна версии 1.11 без нужной сигнатуры. В фатджаре после сборки будет лежать релокнутый шейдером my.cool.app.org.apache.avro.Schema. Но в коде то я не могу обратиться с переименованному классу потому что он ещё не релокнут.
такая либа есть https://code.google.com/archive/p/jarjar/ на этапе сборки грубо говоря все линки в коде которые у тебя были org.apache.avro.Schema переделает в my.cool.app.org.apache.avro.Schema
Не самую свежую, а первую что нашёл и останавливается Поэтому в зависимости от порядка перечисления jar в класпасе если есть одинаковые классы то загрузится первый На этом основана идея когда ты хочешь подменить существующие классы, то ты собираешь их и помещаешь первыми в перечислении
А как определяется этот порядок?
Порядком указанном в класпасе
сначала rt.jar, потом всё остальное в порядке нахождения файлов *.jar
Обсуждают сегодня