Ok, I'm coming back to this discussion as I'm currently looking in how to implement this.
We now have a dynamic class loader manager (commons/classloader bundle) which returns a class loader (proxy) to dynamically load classes. This class loader has two purposes - remove the need for dynamic import package * in script handlers. The new dynamic class loader uses the package admin to find classes. - allow custom dynamic class loaders like a jcr class loader. Therefore we have the new DynamicClassLoaderProvider interface which could be implemented by the JCR class loader. The second point would make the current RepositoryClassLoaderProvider obsolete and should make class loading for compiled scripts working in JCR and non-JCR environments (we could simply make a dynamic class loader provider using a temporary directory). So far this should work - but that's only one side of the coin - loading classes. The more interesting point is how can the script handlers write classes? For this I looked how the JSP engine currently does it's work and it seems to me that this is not that easily changeable. There is the IOProvider which is the interface for IO :) It reads java files, writes class files (or other generated files) etc. Unfortunately all the path handling is done somewhere inside the jsp engine. So instead of having a getInputStream(String javaClassName) and getOutputStream(String javaClassName) both methods use a fileName - so all the path handling etc has already been done. I think we should change this and leave the path handling to a service. For example a (don't quote me on the name) WriteableDynamicClassLoaderProvider could offer methods for getting the output stream to write a class file. The argument would only be the file name. Reading of sources should work through the resource resolver. Just a rough idea, but WDYT? Carsten Felix Meschberger wrote: > 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 > -- Carsten Ziegeler [email protected]
