I solved the issue using cglib proxy class. See my example here. https://github.com/venkatsalem/Groovy-Serialization/tree/master/app/src/main/java
On Wed, Nov 16, 2016 at 6:35 PM, Jochen Theodorou <[email protected]> wrote: > 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 >
