On 16.11.2016 18:30, Venkat Sadasivam wrote:
Hi Jochen
When using Tomcat server and putting the Groovy object into HttpSession
I do not have control over to choose the child classloader for
deserialization hence I thought if I could load into the parent then the
default web app class loader will be able to find the class and
deserialize them.
It would be interesting to know which class loaders are used for
deserialization, because only then we know which one we do have to
"influence". But in general you cannot just load a class into a parent
class loader. The method to define a class is protected. You could maybe
add something to the search path of that loader if it is an URLClassLoader.
Then the problem is the Java script engine. It can load scripts, but
what classloader is used for doing so and if that results in the actual
formation of a class depends on the script engine implementation. The
Groovy script engine will usually spawn its own class loader for that, a
GroovyClassLoader here. It has to, because it has normally no control
over the other loaders.
I find it unlikely that this class loader will be what is used here.
The context class loader could help maybe if you could set it before
deserialization. But probably no solution...
No I think the script engine is not working well for this at all
bye Jochen
