[udig-devel] Classloader bugs in RC8

[Jesse Eichar]

Hi Tony,

The Classloader stuff is done because in certain cases we don't want  
to use the eclipse classloader.  As you've probably know the  
classloader is one that enforces the restrictions declared by the  
plugins and does the auto loading of dependencies.  So when we need a  
"normal" classloader (or a special one for that matter).  We have to  
store the context class loader, make the switch so we can make our  
changes (in these cases change the logging levels in the Geotools  
code which is in the net.refractions.lib classloader) and then in the  
finally block set the context loader back to its original.  Remember  
that the try finally is critical.  If you start running around with  
the wrong classloader you're going to be in big trouble.

Jesse




On Sep 25, 2007, at 5:33 AM, tony.roth at GMX.de wrote:

> Due to other issues we use still the RC8 SDK and found this:
>
> In the following classes
> ShpPlugin
> WfsPlugin
> BasicFeatureRenderer
> RendererPlugin
> ShapefileFeatureRenderer
> BasicWMSRenderer
>
> the ClassLoader has to be saved with
> ClassLoader current = Thread.currentThread().getContextClassLoader();
> instead of using the classloader of the respective class.
>
> I don't know if it's already fixed in a newer version. With RC8 we  
> got strange exceptions since the classloader of some Eclipse Worker  
> Objects (started out of udig classes) was not the same we needed  
> for our RMI communication.
>
> tony roth
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.refractions.net/pipermail/udig-devel/attachments/20070925/544655db/attachment.html