Hi Michael, Michael Dürig schrieb: > > 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
This is not true in general. In fact I never encountered a scripting language which would require this (provided the script language implementation supports compilation into byte code). > 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. 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 > >
