Apache Tika — NoSuchMethodError TarArchiveInputStream.getNextEntry()

Я использую версии:

  • СпрингБот: 3.2.4
  • Ява: JDK 17

Pom использовался как в документации и основывался на моем дереве зависимостей:

  <dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-core</artifactId>
    <version>2.9.2</version>
  </dependency>
  <!-- Uses commons-compress lib with version 1.26.1 -->
  <dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-parsers-standard-package</artifactId>
    <version>2.9.2</version>
  </dependency>
  <!-- Uses commons-compress lib with version 1.24.0 -->
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <scope>test</scope>
    <version>4.13.2</version>
  </dependency>
  <!-- Uses commons-compress lib with version 1.24.0 -->
  <dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>testcontainers</artifactId>
    <scope>test</scope>
    <version>1.19.7</version>
  </dependency>
 

Использование кода:

String htmlFile = "<!DOCTYPE html><html><head><!-- HTML Codes by Quackit.com --><title></title><meta name=\"viewport\" content=\"width=device-width, initial-scale=1\"><style>body {background-color:#ffffff;background-repeat:no-repeat;background-position:top left;background-attachment:fixed;}h1{font-family:Arial, sans-serif;color:#000000;background-color:#ffffff;}p {font-family:Georgia, serif;font-size:14px;font-style:normal;font-weight:normal;color:#000000;background-color:#ffffff;}</style></head><body><h1>test</h1><p>test2</p></body></html>";

Tika tika = new Tika();

// this throw exception
text = tika.parseToString(TikaInputStream.get(htmlFile.getBytes())); 

// This is not working too - same exception
text = tika.parseToString(new ByteArrayInputStream(htmlFile.getBytes()));

Исключение – соответствующая часть:

java.lang.NoSuchMethodError: 'org.apache.commons.compress.archivers.tar.TarArchiveEntry org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry()'
at org.apache.tika.detect.zip.TikaArchiveStreamFactory.detect(TikaArchiveStreamFactory.java:293) ~[tika-parser-zip-commons-2.9.2.jar:2.9.2]
at org.apache.tika.detect.zip.DefaultZipContainerDetector.detectArchiveFormat(DefaultZipContainerDetector.java:124) ~[tika-parser-zip-commons-2.9.2.jar:2.9.2]
at org.apache.tika.detect.zip.DefaultZipContainerDetector.detect(DefaultZipContainerDetector.java:175) ~[tika-parser-zip-commons-2.9.2.jar:2.9.2]
at org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:84) ~[tika-core-2.9.2.jar:2.9.2]
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:177) ~[tika-core-2.9.2.jar:2.9.2]
at org.apache.tika.Tika.parseToString(Tika.java:525) ~[tika-core-2.9.2.jar:2.9.2]
at org.apache.tika.Tika.parseToString(Tika.java:495) ~[tika-core-2.9.2.jar:2.9.2]
at org.apache.tika.Tika.parseToString(Tika.java:557) ~[tika-core-2.9.2.jar:2.9.2]
at ... -> tika.parseToString(...

Я пытался использовать другой подход для анализа тики, но получил то же исключение, что и при отладке — первый подход использует второй в библиотеках тика — я попробовал этот второй подход:

AutoDetectParser parser = new AutoDetectParser();
BodyContentHandler handler = new BodyContentHandler();
Metadata metadata = new Metadata();
parser.parse(TikaInputStream.get(htmlFile.getBytes()), handler, metadata);
text = handler.toString();

Я попробовал использовать версию Tika 2.9.1, и все работает нормально, как и несколько месяцев назад.

Но мне нужны последние версии без уязвимостей. Итак, я попытался удалить tika-parsers-standard-package из pom, и когда я отлаживал библиотеки tika, он пошел дальше, но вернул просто пустой текст из-за отсутствия синтаксического анализатора для HTML-подобных файлов (как я отлаживал в библиотеках tika), логически. Так в библиотеках какая-то ошибка тики или я что-то не так делаю?

Вы жестко запрограммировали зависимость от более старой версии Commons Compress?

Gagravarr 12.04.2024 14:19

Нет, но я попробовал сейчас, это странно, я объявил зависимость pom от commons-compress lib с версией 1.26.1 ниже зависимостей tika, и теперь она работает даже с tika 2.9.2. Спасибо, можете написать это как ответ, я приму. Жесткое кодирование Commons-Compress зависимости снова ниже зависимостей tika помогло - но раньше я видел в дереве зависимостей, что tika 2.9.2 использует commons-compress1.26.1, но это не сработало.

Marek Bernád 12.04.2024 14:52

В моем дереве зависимостей также показаны места, где используется commons-compress: - junit:junit:jar:4.13.2 - org.apache.tika:tika-parser-webarchive-module:jar:2.9.2 - org.testcontainers:testcontainers: jar:1.19.7, но все эти зависимости используют commons-compress 1.24.0, но tika 2.9.2 использует 1.26.1... и без объявления commons-compress в pom с версией 1.26.1 эти библиотеки каким-то образом конфликтуют друг с другом после добавление 1.26.1 commons-compress - junit и testcontainers тоже используют 1.26.1... Я обновлю pom в своем вопросе

Marek Bernád 12.04.2024 15:22
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
3
284
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Поэтому я опубликую ответ для других с той же проблемой. Мне это помогло:

    <dependency>
      <groupId>org.apache.tika</groupId>
      <artifactId>tika-core</artifactId>
    <version>2.9.2</version>
    </dependency>
    <dependency>
      <groupId>org.apache.tika</groupId>
      <artifactId>tika-parsers-standard-package</artifactId>
      <version>2.9.2</version>
    </dependency>

    <!-- By adding this the problem is solved -->
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-compress</artifactId>
      <version>1.26.1</version>
    </dependency>

Я также исследовал, почему это происходит, с помощью следующей команды:

mvn dependency:tree -Dverbose | grep 'omitted for conflict' | grep 'commons-compress'

Ответ команды в моем случае:

[INFO] |  |  |  +- (org.apache.commons:commons-compress:jar:1.25.0:compile - omitted for conflict with 1.26.1)
[INFO] |  |  |  \- (org.apache.commons:commons-compress:jar:1.26.1:compile - omitted for conflict with 1.24.0)
[INFO] |  |  |  +- (org.apache.commons:commons-compress:jar:1.25.0:compile - omitted for conflict with 1.24.0)
[INFO] |  |  \- (org.apache.commons:commons-compress:jar:1.26.1:compile - omitted for conflict with 1.24.0)

Это означает, что Тика использовала версию 1.24.0 из-за конфликтов в транзитивных зависимостях между tika-parsers-standard-package и junit/testcontainers зависимостями. При жестком кодировании библиотеки commons-compress в версию 1.26.1 все зависимости использовались 1.26.1commons-compress, поэтому Тика тоже использовала правильную версию и теперь работает как положено.

Другие вопросы по теме