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).
Hmm, this is probably more a problem of the Design of the respective
scripting language, than one of the ClassLoader. The Java ClassLoader is
not a generic resource accessor with API to walk some package tree. The
ClassLoader allows direct access to classes (and resources).
And this is good and sufficient.
No I think it isn't. Class loaders were designed to load binary
representations of classes into the JVM. Using them for scripting
languages which need to resolve symbols at compile time is a hack. In
fact all languages which I looked at and which do symbol resolution at
compile time use the same 'classloader.getResource("foo.class")' hack to
get access to a class file. Languages which require to browse the
classes available to them at compile time need to resort to even more
esoteric hacks.
Now this is certainly not a problem of Sling. Given however, that Sling
has support for a great variety scripting languages and that each of
those makes certain assumptions on the representation of the
'classpath', there will be more or less of a hassle for each of it to
get it working within Sling.
So the decision is whether we leave this to integrators of scripting
languages and let each of those come up with its own - possible brittle
solution - which in the worst case might depend on implementation
details of actual class loaders. Or whether we provide some means to
them which makes their lives easier and which factors out potential
problematic/implementation dependent code. After all the latter
'solution' will facilitate integration of new scripting languages and
enhance stability and maintainability.
Michael
The problem with the Scripting Language you are talking about is, that
it is not using the ClassLoader as the ClassLoader is intended to be
used. It tries to enumerate classes and resources, which is only
possible if you can access the resources upon which the class loader
operates, but this functionality is outside of the general ClassLoader API.
In the case of the OSGi framework such functionality might in addition
violate or break the separation of concerns mechanisms built using the
Import/Export declarations.
BTW: Are there language with built-in functionality to find all
implementations of a given interface ? This sounds more like an IDE
feature which indexes the class space, than like a language feature....
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'.
The problem must really be solved in Scala, which IMHO has no reason to
know the source of the class path entries as long as it can ask the
ClassLoader for classes and resources.
Regards
Felix
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
