Is it possible for us to answer the underlying question about classloaders?

We have never seen this problem specifically, because we require our users to install JAI, and give them the option of installing JAI ImageIO tools. We are typically in a non-internet-connected environment and thus aren't able to point to a WebStart extension installer. Therefore if we DID run into such a problem, that solution wouldn't help us.

The problem seems to be that libraries installed in lib/ext have tighter access restrictions than those in the core JRE, from a classloader perspective. This indicates to me that a separate, secured classloader is used for lib/ext, without visibility to the application classloader. What's puzzling to me is that this would have to affect any JAI plugins (e.g. OperationRegistrySpi) that are loaded from the application's classpath (rather than from lib/ext). We don't use this particular behavior so we've never run into a problem.

Obviously classes loaded from the core JRE (e.g. rt.jar) do not have the same security restrictions; otherwise the entire ImageIO framework would be badly broken.

does anyone have any thoughts on how the classloaders are divided? Is it different in WebStart from a normal invocation of the java or javaw commands? Is there a complex classloader hierarchy?

Perhaps there's documentation on the JVM behavior somewhere but I haven't been tenacious enough to track it down.

Mike