К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

Конфликт имен: как разрешить?

0 - 06.10.2017 - 11:21
Всем привет.
Столкнулся с проблемой. Пишу код, использовал в процессе библиотеку org.jsr107.ri. Пишу, отлаживаю, все хорошо. Через gradle оно замечательно запускается... собираю war-файл, скармливаю его томкату - и получаю эксепшн:

java.util.ServiceConfigurationError: javax.cache.spi.CachingProvider: Provider org.jsr107.ri.spi.RICachingProvider could not be instantiated
...
Caused by: java.lang.IncompatibleClassChangeError: Implementing class

Запускаю томкат с $JAVA_OPTS -verbose:class - вижу, что класс javax.cache.CacheManager загружается из файла appengine-api-1.0-sdk-1.9.57.jar.
При этом, в cache-api-1.0.0.jar есть интерфейс javax.cache.CacheManager. И если верить JSR107 - должен быть именно интерфейс.

Вопрос номер 1 - чтозанафиг?
Вопрос номер 2 - что с этим делать?
Если из файла appengine-api-1.0-sdk-1.9.57.jar удалить неугодные классы, или хотя бы переименовать его в zappengine-api-1.0-sdk-1.9.57.jar - все запускается. Но как-то это криво.

Как бы это получше обойти? Чтобы автоматизированно. Вручную в gradle переименовать файл? Может, есть способ указать порядок загрузки из WEB-INF/lib? Или загружать из jar не все файлы? Миграцию на джаву9 не предлагать.



1 - 06.10.2017 - 18:05
если у вас томкат, то откуда 'appengine-api-1.0-sdk' ?
2 - 06.10.2017 - 21:25
не понял вопроса. Разве они исключают друг друга?

Во-первых, его тянет spring boot.
Во-вторых, его тянут библиотеки для работы с гугловским oauth2, и еще штук 6 библиотек, которыми мы пользуемся.
3 - 07.10.2017 - 03:16
ОМГ. Знаток ассемблера, ведь всего-то нужно "обернуть в свой намеспейс".
4 - 07.10.2017 - 20:34
а можно поподробнее? Как это на джаве сделать? Подозреваю, что никак.

Обращаю внимание, что это не моя библиотека, и я не могу просто взять и переименовать класс\перенести его в другой пакет.
5 - 07.10.2017 - 23:23
>Во-первых, его тянет spring boot.

наверняка не сам спринг бут, а бутстартеры, а они тянут много всякой фигни

в общем надо смотреть нужная ли эта библиотека, то что она тянется этого не означает
6 - 08.10.2017 - 01:06
Я нашел ссылку на него в
spring-boot-1.5.2.RELEASE.jar!/META-INF/maven/org.springframework.boot/spring-boot/pom.xml
плюс еще в 5-6 библиотеках.

Ну да ладно. А если предположить, что отказаться от этой библиотеки я не могу. Что часть классов, уникальных для этой библиотеки, мне нужна, а остальные - нет.
Сейчас изучаю плагин для грейдла - fatjar (и в частности - применимость его к war-файлам), но все равно мне это кажется костылем.
7 - 13.10.2017 - 16:25
Цитата:
Сообщение от Добрых дел мастер Посмотреть сообщение
Я нашел ссылку на него в
Это плохо:

Код:
<dependency>
  <groupId>com.google.appengine</groupId>
  <artifactId>appengine-api-1.0-sdk</artifactId>
  <scope>test</scope>
</dependency>
Намекаю: scope=test - означает что зависимость не нужна в продакшене

А градл может подтягивать все зависимости, в зависимости от кучи нюансов.
8 - 13.10.2017 - 20:16
1. Намек понятен. Но эта библиотека подтягивается и из других мест, которые нужны не только на этапе тестирования. Плюс, это только грейдлу\мавену понятен этот скоуп. А когда томкат загружает классы - кто первый по алфавиту, тот и молодец.
2. Вообще, вопрос в,
- какого хрена гугл нарушает спецификацию.
- какого хрена гугл кладет в свои библиотеки классы из совсем другого неймспейса (тут и без нарушения спецификации хватит конфликтов)
- Что в этом случае делать.
Мне кажется, хорошим решением было бы, если бы в gradle можно было указать, какие модули грузить, а какие нет.
Но это (если я все правильно понял) можно сделать только на этапе компиляции. Дальше он упаковывает исходные jar-файлы - и на этапе загрузки у нас куча не нужного.
Я поигрался с класслоадерами - лучше, чем переименовывать jar, но если честно - все равно костыль.
Кажется, в этом должна помочь jigsaw?
9 - 14.10.2017 - 00:31
>Но эта библиотека подтягивается и из других мест, которые нужны не только на этапе тестирования. Плюс, это только грейдлу\мавену понятен этот скоуп.

всё не так, этот скоуп означает, что библиотека нужна только для тестирования spring-boot. То бишь пользователю spring-boot она не нужна. Это важно. Это означает, что в релизном наборе библиотек её вообще не должно быть по этой зависимости.

И единственный верный путь - это нырнуть в этот dependency hell (т.е. почитать про мавен, его скоупы и то как на всё это ложил гребанный градл с пробором) и разобраться какого хрена (и по какой зависимости) она пролезает в финальную сборку.
10 - 14.10.2017 - 01:20
вот, как раз этим и занимаюсь.
Если честно, пока тяжеловато дается.
11 - 19.10.2017 - 23:31
боже, как же хорошо, что я ушел с этой жабы на шарп...
у меня до сих пор тройные фейспалмы, когда я вспоминаю синтаксис джавы.
особенно чтение из буфера и многопоточность.

а сбор проекта - это вообще квест в квесте...
спасибо тебе боженька за это!
12 - 20.10.2017 - 11:50
А что не так? Можно пару примеров, чем шарп в данной ситуации лучше?

Ну и время идет, джава меняется. Давно это было?
Вон и с этой проблемой со сборкой должен помочь jigsaw, правда подробно не изучал.
13 - 20.10.2017 - 19:41
столько технологий только для того, чтобы собрать проект..
проблема жабы в ее преимуществе.
именно ее обратная совместимость рождает таких мутантов как соуты, или, к примеру, чтение из буфера:
try(BufferedReader br = new BufferedReader (new InputStreamReader(System.in));
BufferedWriter bw = new BufferedWriter(new FileWriter("D:\\notes5.txt")))

этим кодом сотону вызвать можно.

и так в джаве везде.


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены