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+unsubscr...@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/groups/opt_out.
