You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Class loader of application A having its own jai-image-core.jar in its classpath
Class loader of application B having its own jai-image-core.jar in its classpath
This is the kind of classloader tree that is used in a webapp container like tomcat.
ImageIO is loaded by the class loader system since it resides in the jdk.
Suppose also that:
At startup, application A launches ImageIO.scanForPlugins()
At startup, after app A, application B launches ImageIO.scanForPlugins()
When application B calls ImageIO for any operation, ImageIO will scan its plugin registry and return the first plugin able to fullfill the operation.
But in our specific case, the plugin returned by the registry, to application A, will be the one loaded by Application B class loader !
Therefore, plugin instances are leaking between class loaders on WebApp containers.
Maybe this bug should be handled by the JVM vendors, but knowing their reactivities, I propose to handle this issue in each plugin by checking that the current thread classloader or one of its parent loaded the plugin class about to be used.
Incoming PR
The text was updated successfully, but these errors were encountered:
reda-alaoui
changed the title
Plugin instances leaking between class loaders
Plugin instances leak between class loaders
Jan 6, 2017
reda-alaoui
changed the title
Plugin instances leak between class loaders
Plugin instances leak between sibling class loaders
Jan 6, 2017
Suppose we have a JVM running 3 class loaders:
jai-image-core.jar
in its classpathjai-image-core.jar
in its classpathThis is the kind of classloader tree that is used in a webapp container like tomcat.
ImageIO is loaded by the class loader system since it resides in the jdk.
Suppose also that:
ImageIO.scanForPlugins()
ImageIO.scanForPlugins()
When application B calls
ImageIO
for any operation,ImageIO
will scan its plugin registry and return the first plugin able to fullfill the operation.But in our specific case, the plugin returned by the registry, to application A, will be the one loaded by Application B class loader !
Therefore, plugin instances are leaking between class loaders on WebApp containers.
Maybe this bug should be handled by the JVM vendors, but knowing their reactivities, I propose to handle this issue in each plugin by checking that the current thread classloader or one of its parent loaded the plugin class about to be used.
Incoming PR
The text was updated successfully, but these errors were encountered: