There is another issue with the current design which might be worthwhile
to tackle at the same time. While class loaders are fine for loading
classes into the JVM they are in general the wrong abstraction when
compiling scripts. Scripts need access to the class files itself and
might even need to browse the available classes on the 'classpath'. This
might for example be the case for languages which have some built in
dependency injection support (i.e. find me all available implementations
of a given interface).
I faced this issue when I implemented support for Scala [1]. To work
around it I implemented a (Scala specific) file system abstraction on
top of Felix's bundles [2]. While this works atm, the approach might not
be too stable. Since others might face similar problems, we could maybe
provide a more standardized way to Scripts for accessing classes on the
'classpath'.
Michael
[1]
http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/scala
[2]
http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/scala/interpreter/src/main/scala/org/apache/sling/scripting/scala/interpreter/BundleFS.scala
Carsten Ziegeler wrote:
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?
Carsten
