Impossible de charger la classe javax.imageio.ImageIO dans WAS 8.5

Question

Je ne parviens pas à charger la classe ImageIO de JAI 1.3.0. Java 6 et Web Application Server (WAS) 8.5. Mon code fonctionne correctement pour Java 6 et WAS (7.0.19).

J'ai mentionné la dépendance correctement dans pom. Besoin de savoir si quelqu'un a le même problème ou non.

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

Il semble que mon serveur n'est pas classe capable charge ImageIO lors de l'exécution, d'où image valeur est nulle à venir. Je passe le fichier au format Tiff en imagesVO.

Answer 1

Il y avait un changement de comportement dans WAS 8.5 concernant la bibliothèque ImageIO, dans le cadre de la logique de prévention des fuites du chargeur de classe ajoutée dans cette version. Lorsque la prévention des fuites est activée, la bibliothèque ImageIO est immédiatement instanciée dans le cadre du processus de démarrage du serveur, dans le but de l'empêcher de se lier (de manière permanente, car elle n'est pas compatible avec le chargement dynamique des classes Java EE). classe d'implémentation. L'effet secondaire, cependant, est que puisque la bibliothèque est instanciée avant que les classes d'application ne soient présentes, les plugins fournis par l'application ne pourront pas être localisés.

Il y a quelques solutions de contournement possibles pour cela:

1) appeler Explicitement ImageIO.scanForPlugins() avant d'effectuer votre opération. Cela indiquera à ImageIO de faire une nouvelle analyse pour les classes de plugins en utilisant le chargeur de classes de contexte de thread, et le vôtre sera récupéré. Notez que cela entraînera une référence permanente de la bibliothèque ImageIO au niveau système à votre classe d'application, donc le chargeur de classe sera divulgué si vous redémarrez l'application sans redémarrer la JVM (ceci est déjà arrivé dans les versions précédentes de WebSphere, donc probablement n'est pas un énorme problème pour vous).

2) Désactivez la prévention des fuites du chargeur de classe sur votre serveur. Vous pouvez le faire avec une propriété système (com.ibm.ws.runtime.component.disableMemoryLeakService = true). La même mise en garde s'applique en ce qui concerne la fuite du chargeur de classe.

3) Ajoutez la bibliothèque ImageIO nécessaire à votre chemin de classe JVM. Les situations qui appellent une modification de chemin de classes au niveau JVM sont extrêmement rares, mais c'est l'une d'entre elles: ImageIO recherche les plugins au démarrage du serveur, trouve votre plugin (car il se trouve dans le chemin de la classe JVM) et bonus il ne fuira pas votre chargeur de classe d'application.