If I want to invoke ScriptingUtil from a plugin, and the script need to access any class defined in the plugin, obviously I need to provide plugin class loader as a parameter of the exec or eval method. And this seems could be default behavior if the ScriptingUtil is invoked from a plugin instead of portal.
As a bottom line, if we must specify the plugin classloader as a parameter explicitly, as current implementation I have to specify PortalClassLoader together with the portlet classloader, since if I missed the PortalClassLoader in the parameter list, I will always get ClassNotFoundException since the script executor implementation is reside in the portal classloader. ScriptingUtil should always make sure the classloader that implements the specific script language executor is included in the behind AggregatedClassLoader.
And IMHO it really shouldn't be the ScriptingUtil's users responsibility to care about this: The built-in script language support class may reside in the PortalClassLoader, but some extended script language support class may reside in a web or hook plugin.
