Hi Carsten,
Carsten Ziegeler schrieb:
> I'm thinking about improving our jsp (and other scripting) support. One
> problem I see atm is our class loading for compiled scripts.
>
> At the moment, we have the RepositoryClassLoaderProvider which allows to
> get a class loader for a user which is able to load classes from
> somewhere out of the repository. All the scripting support for writing
> classes into the repository have to know where in the repository classes
> are located. The scripting engines write the compiled script to this
> configured locations and later on the class is loaded by the
> RepositoryClassLoader. Obvioulsly this has at least two drawbacks:
> - The repository path where classes are located has to be configured
> properly at several places
> - The scripting support is tied to jcr which makes it unusable in non
> JCR environments
>
> I think we should come up with a solution for these problems by
> introducing a ResourceClassLoaderProvider with a similar interface as
> the RepositoryClassLoaderProvider. I'm not sure about the user argument
> especially if we plan to use the OSGi User Admin stuff.
>
> The provider could provide a ResourceClassLoader which extends
> ClassLoader and has an additional method for writing class files and
> maybe removing them (perhaps we need more functionality?)
>
> WDYT?
+1 for a ResourceClassLoader
Maybe we should even register the ResourceClassLoader as a globally
available service with the following properties:
* The service is really a proxy, since upon class changes, the
real class loader used is replaced.
* The class loader service is shared by all clients using classes
(or resources) from the ResourceClassLoader
* The locations from where the class loader is loading classes and
and resources is queryable, similar to URLClassLoader.getURLs()
* The ResourceClassLoader must only be used for short-lived use of
classes and resources.
The last point is important, since the actual class loader will be
dropped upon changes in the class path. If we would be referring to
classes over an extended period of time, we would run into memory issues
(the classloader and all loaded classes cannot be collected) and class
cast exceptions.
Regarding "user specific classloaders": I don't think, we really need
this (any more). It has not been implemented in the current release (the
class loader is always using the administrative session) and I don't see
a use in it (right now).
Regards
Felix
>
> Carsten
