Задача обновить версию log4j с 1.2.15 до 2.17.1, но она

тянется транзитивно.
В документации написано: "A version will always be honoured if it is declared in the current POM with a particular version - however, it should be noted that this will also affect other poms downstream if it is itself depended on using transitive dependencies."

На maven repository для артифакта последняя версия 1.2.17 и написано: "Note: This artifact was moved to: org.apache.logging.log4j » log4j-core", то есть прописать для меня этот способ не сработает, так как по сути уже другой артифакт.
Тогда я могу для через exclusions исключить из зависимости log4j и через dependencies добавить log4j-core версии 2.17.1. Это нормальное решение?

Да, по-другому и не сделать. Убедись только, что ты заэкслудил все места, отуда log4j растёт. Их может быть несколько.

а из какого репозитория тогда брать 2 версию? несколько репозиториев?

В принципе, я так бы и делал. Но надо проверить. Наверняка возникнет проблема с теми библиотеками, из которых ты его исключишь. Они же зависят от него, он им нужен, чтобы логировать что-то.

лучше конечно зависеть на slf4j и подключать то что ниже по ситуации если библиотека сама хочет старый log4j то насильно отрезав и добавив - могут ждать сюрпризы...

Не совсем понял. Репозиторий один - maven repository, просто артифакт переехал. Насколько я понимаю, технически это уже новый артифакт

Да вроде бы slf4j и есть, но в одной из зависимостей log4j и потребовали обновить версию

а dependency:tree что говорит. ну вроде ты понял мой поинт - насколько там зависимость именно про API

Ну так сделать exclude на старую и добавить новую

Очень маленький шанс. Обратная совместимость у них хорошо развита

Что в зависимости условно уровня B есть некая one-nio (уровня C), которая зависит на log4j старый. Вот не знаю, сломается ли что-то, видимо это непросто понять, куча всего на библиотеке уровня B в приложении. Я так понимаю понять сломается ли что-то очень непросто

а если той библиотеке нужен старый log4j?

Так можно попробовать. Библиотека работает через log4j api

@swswsw202 @spyroid Не взлетело приложение из-за того что нет log4j, что-то вроде такого Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘SomeService' defined in URL [jar:file:/path/SomeService.class]: Bean instantiation via constructor failed; nested exception is java.lang.NoClassDefFoundError: org/apache/log4j/Logger ... Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at package.SomeService.<clinit> (SomeService.java:15) …. Какие ещё есть варианты, кроме как обновить саму либу, которая зависит от log4j?

"org.apache.logging.log4j" % "log4j-1.2-api" % "2.17.1”

Это же что-то для сборщика sbt, а у меня maven. Не совсем понял, где можно посмотреть?

да никаких особо. Ну распилить на два приложения, запускать на разных jvm и общаться по rmi. Мама, я не наркоман.

да не поможет тебе, там сменилось имя артефакта во 2 версии, технически, с точки зрения мавена это вообще совершенно другой артефакт

Нельзя просто так взять и поменять мажорную версию либы (т.е. 1 на 2)

А какая либа требует log4j у тебя?

Внутренняя библиотека банка

увольняйся

А разве в таких случаях не гарантируется, что мейнтейнеры сидят в соседнем кабинете и могут её обновить?

Другими словами её должны обновить те, кто её поддерживает. По-хорошему, твоему лиду надо об этом сказать, чтобы он поставил задачу вашим коллегам.

Может, он и мейнтейнер? 🙂

Возможно просто мы сидим на старой версии библиотеки. Тогда придётся ее обновлять, а это уже огромная задача, много всего переписать возможно придётся Видимо, к этому всё и идёт

Ах, классика

Зачем вы её вообще обновляете, опасная уязвимость есть только в версии 2. В первой есть проблема, но она достаточно экзотическая.

Ну вот требования такие поставили. Думаю проще доказать, что это не нужно, тому, кто предъявил требования, чем обновлять всю основную библиотеку приложения. Хотя может не проще, банк же