Re: Error using IMAGE/IO in a Servlet

Wow.  this really saved me as well. Thx so much for posting. I had tried lots of things to get the tiff writers to load using the correct class loader; nothing I tried worked. But this did - saved me from having to rewrite a lot of code so just a +1 on how cool a trick this is :)

On Thursday, September 4, 2014 at 3:27:31 PM UTC-6, Paul Bartlett wrote:

After another million years I have been trying various things out and I found that if I add ImageIO.scanForPlugins(); before the calls it loads the tiff image writers from the WEB_INF/lib directory.   This is better than disabling memory leak protection.

On Tuesday, 29 October 2013 04:29:49 UTC-7, Sean wrote:

Wow, 

Thank you Jens. I would have never figured that out in a million years! That was super subtle, but I learned a lot from it!

Thank you! Your suggestion worked perfectly!

-Sean

On Monday, October 28, 2013 4:17:13 PM UTC-4, Jens wrote:

This kind of ClassCastException typically occurs if you have a ClassLoader issue. If the same class is loaded by two different ClassLoader then Java treats these two classes as different and its likely that you get the above ClassCastException.

First I would make sure that you have the imageIO.jar only once in your class path and then you could check if you have a ClassLoader leak when you redeploy your application. 

A ClassLoader leak isn't that unlikely because the first call to ImageIO pins the current ClassLoader. If that's the WebAppClassLoader that is responsible for your app, the app server (jetty) can not garbage collect your deployed app once you redeploy it because some Java system classes will hold a reference to that WebAppClassLoader...well and this reference will never go away unless you restart the server. 

If you are in that situations then its likely that everything works the first time you start Jetty and it will start to fail once you have redeployed your app the first time. 

To fix this situation you could try using a ServletContextListener and in its contextInitialized() method you first change the class loader of the current thread to the system class loader. Then you make a dummy call to ImageIO and finally you set back the class loader to the original one.

In our app we have to do that for multiple classes because libraries (and Java) are sometimes written in a way thats not very compatible to application server class loading.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.