无法在WAS 8.5中加载javax.imageio.ImageIO类 [英] Not able to load javax.imageio.ImageIO class in WAS 8.5

查看:134
本文介绍了无法在WAS 8.5中加载javax.imageio.ImageIO类的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我无法加载JAI 1.3.0的ImageIO类. Java 6和Web应用程序服务器(WAS)8.5.我的代码在Java 6和WAS(7.0.19)上运行良好.

I am not able to load ImageIO class of JAI 1.3.0. Java 6 and Web Application Server (WAS) 8.5. My code is working fine for Java 6 and WAS(7.0.19).

我在pom中正确地提到了依赖性.需要知道是否有人遇到相同的问题.

I have mentioned dependency properly in pom. Need to know if any one has same issue or not.

byte[] imgBytes = imagesVO.getImgBytes();
BufferedImage image = ImageIO.read(new ByteArrayInputStream(imgBytes));

似乎我的服务器在执行过程中无法加载ImageIO类,因此image的值变为空.我在imagesVO中传递了Tiff格式文件.

It seems my server is not able load ImageIO class during execution, hence image value is coming null. I am passing Tiff format file in imagesVO.

推荐答案

在WAS 8.5中,有关ImageIO库的行为发生了变化,这是该发行版中添加的某些类加载器防泄漏逻辑的一部分.启用防泄漏功能后,ImageIO库将在服务器启动过程中立即实例化,以防止其链接(永久,因为它对Java EE类加载的动态特性不友好)到应用程序提供的链接实现类.但是,副作用是,由于在应用程序类出现之前实例化了库,所以将无法找到任何应​​用程序提供的插件.

There was a behavior change in WAS 8.5 regarding the ImageIO library, as part of some class loader leak prevention logic added in that release. When leak prevention is enabled, the ImageIO library is immediately instantiated as part of the server startup process, with the goal of preventing it from linking (permanently, since it's not friendly to the dynamic nature of Java EE class loading) to an application-provided implementation class. The side effect, though, is that since the library is instantiated before application classes are present, any application-provided plugins will fail to be located.

有一些潜在的解决方法:

There are a few potential workarounds for this:

1)在执行操作之前,明确调用ImageIO.scanForPlugins().这将告诉ImageIO使用线程上下文类加载器对插件类进行重新扫描,然后您的插件将被取走.请注意,这将导致从系统级ImageIO库到您的应用程序类的永久引用,因此,如果您在不重新启动JVM的情况下重新启动应用程序,则类加载器将被泄漏(这已经在以前的WebSphere版本中发生,因此可能对您来说不是一个大问题).

1) Explicitly call ImageIO.scanForPlugins() before you perform your operation. That will tell ImageIO to do a rescan for plugin classes using the thread context class loader, and yours will get picked up. Note that this is going to cause a permanent reference from the system-level ImageIO library to your application class, so the class loader will be leaked if you restart the application without restarting the JVM (this happened in previous WebSphere versions already, so this probably isn't a huge problem for you).

2)禁用服务器中的类加载器泄漏防护.您可以使用系统属性(com.ibm.ws.runtime.component.disableMemoryLeakService = true)进行此操作.关于类加载器的泄漏,同样的警告.

2) Disable the class loader leak prevention in your server. You can do this with a system property (com.ibm.ws.runtime.component.disableMemoryLeakService=true). The same caveat applies regarding the leakage of the class loader.

3)将必要的ImageIO库添加到JVM类路径.要求进行JVM级类路径修改的情况极少,而且相差无几,但这只是其中一种-ImageIO将在服务器启动期间扫描插件,找到插件(因为它在JVM类路径中),并且作为好处是它不会泄漏您的应用程序类加载器.

3) Add the necessary ImageIO library to your JVM class path. The situations that call for JVM-level class path modification are extremely few and far between, but this is one of them - ImageIO will scan for plugins during server startup, find your plugin (since it's in the JVM class path), and as a bonus it won't leak your application class loader.

这篇关于无法在WAS 8.5中加载javax.imageio.ImageIO类的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆