javax.imageio.IIOException: не удается создать ImageInputStream в Tomcat 9, OpenJDK 11 и Geoserver - PullRequest
2 голосов
/ 05 марта 2019

При работе с javax.imageio.IIOException: не удается создать ImageInputStream! после вызова ImageIO.read (файл файла) из-за отсутствия FileImageInputStreamSpi *Поставщик 1006 * Я обнаружил, что поставщики услуг ImageIO , доступные в моем веб-приложении, зависят от того, работает ли веб-приложение Geoserver (http://geoserver.org) в том же веб-контейнере Tomcat):

Работает только мое веб-приложение:

  • Поставщик услуг, который создает FileImageInputStream из RandomAccessFile
  • Поставщик услуг, которыйсоздает экземпляр FileImageInputStream из File
  • поставщика услуг, который создает экземпляр FileCacheImageInputStream или MemoryCacheImageInputStream из InputStream

Мое веб-приложение, работающее вдоль Geoserver 2.15.0 webapp:

  • NIO Channel ImageInputStream
  • Поставщик услуг, который упаковываетFileImageInputStream
  • Поставщик услуг, который помогает подключаться к объекту, указанному строкой
  • Поставщик услуг, который помогает подключаться к объекту, указанному URL-адресом
  • Поставщик услуг, который создает экземпляр FileImageInputStream из файла RandomAccessFile

Код в моем веб-приложении:

IIORegistry reg = IIORegistry.getDefaultInstance();
Iterator<ImageInputStreamSpi> it = reg.getServiceProviders(ImageInputStreamSpi.class, true);
while (it.hasNext()) {
    ImageInputStreamSpi spi = it.next();
    System.out.println(spi.getDescription(Locale.GERMAN));
}

Я используюTomcat 9.0.16 webapp и OpenJDK 11.

Интересно, почему оба веб-приложения могут мешать таким образом - разве это не проблема безопасности?

Спасибо за некоторые общие разъяснения.

1 Ответ

4 голосов
/ 05 марта 2019

Это известная проблема с ImageIO и IIORegistry.Экземпляр реестра используется всеми приложениями в виртуальной машине.И это часто вызывает проблемы, как в вашем случае.

Я написал немного о Развертывании плагинов ImageIO в веб-приложении в файле readme для проекта TwelveMonkeys ImageIO.Использование прослушивателя контекста может помочь с некоторыми проблемами, но это не решает основную проблему.

Другое исправление заключается в развертывании плагинов ImageIO только как части самого сервера (т. Е. Общей папки lib), чтобы сделатьуверен, что все веб-приложения видят одинаковые плагины.


Если вы посмотрите глубоко в исходный код IIORegistry, вы увидите, что он действительно имеет некоторую поддержку нескольких реестров, но они привязаны к AppContext s (используется апплетами, webstartи т.д.), что, к сожалению, не совпадает с контекстом веб-приложения.Похоже, должно быть возможно сделать так, чтобы у веб-контекстов были разные AppContext с, если бы они использовали разные ThreadGroup с.Но я никогда не нашел способа заставить сервер приложений назначать разные группы потоков для каждого контекста веб-приложения.

...