Thanks Andrea, Jesse, I now at least know the proper way to do things. 0) put "Eclipse-BuddyPolicy: ext" in the manifest file 1) have jai installed in your java installation 2) whenever you supply a product to someone, supply also the jre of that java installation
That way for me it works nice and clean. Did I get it right? Ciao Andrea Jesse Eichar probaly wrote: > We always use the JAI that is installed in the ext directory. Where is > this code being called from? Every plugin that uses JAI must add the line: > > Eclipse-BuddyPolicy: ext > > In your manifest.mf file. > > This states that the extensions in the JVM's lib/ext directory will be > available on the classpath of that plugin. It could be that the method > you are using is getting the File from the wrong classloader (the lib > one perhaps). > > If you can give me some details about what you're doing I might be able > to come up with a better answer. > > Jesse > > > On Apr 4, 2007, at 6:28 AM, Andrea Antonello wrote: > >>>> Hi folks, I have (once again) a problem with jai: >>>> >>>> java.lang.ClassCastException: >>>> com.sun.media.jai.imageioimpl.ImageReadWriteSpi >>>> at >>>> javax.media.jai.OperationRegistry.registerServices(OperationRegistry.java:2047) >>>> >>>> at >>>> javax.media.jai.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:612) >>>> >>>> at >>>> javax.media.jai.OperationRegistry.initializeRegistry(OperationRegistry.java:365) >>>> >>>> at javax.media.jai.JAI.<clinit>(JAI.java:560) >>>> >>>> >>>> So what is the best practice? >>> >>> The best practice is the harder to attain. You should have the JAI jars >>> installed directly into your JDK, and don't have them anywhere in the >>> classpath. Otherwise you're bound to issues as soon as a damned >>> classloader does not play exactly by the Sun rules. Sigh... >> >> Yes, but that gives me big troubles when I have to export a product. I >> usually somehow have some reference in it and when not it fails because >> there is some dependency. I agree with the fact that this is a problem >> of mine and that I should know a bit better how exactly to do a clean >> and proper export of an eclipse product, but things would be much easier >> if the lars could be put in the classpath and the .so in the library >> path :) >> >>> The issue is that JAI is packaged as an extension, and it's sealed. >>> We still haven't tried hacking the official jars and remove the sealing >>> markers, but that would be an interesting test too (that is, to check if >>> this way JAI can be handled both in the JDK/JRE and in the classpath). >> >> Oh, that is something I didn't know, the sealing thing I mean. I >> remember there was also a download version for classpath use. Hmmm... >> I'll have to check. >> >> Thanks for the informations, >> Ciao >> Andrea >> >> >> >> >> >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel > -- ____________________________________________________________________________ HydroloGIS - Environmental Safety Modelling www.hydrologis.com Andrea Antonello Environmental Engineer mobile: +393288497722 "Let it be as much a great honour to take as to give learning, if you want to be called wise." Skuggsja' - The King's mirror - 1240 Reykjavik ____________________________________________________________________________ _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
