| 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> А градл может подтягивать все зависимости, в зависимости от кучи нюансов. | | |
| 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"))) этим кодом сотону вызвать можно. и так в джаве везде. | |
Интернет-форум Краснодарского края и Краснодара |
