Introduce a ClassReader for scripts which need to do symbol resolution at
compile time
--------------------------------------------------------------------------------------
Key: SLING-945
URL: https://issues.apache.org/jira/browse/SLING-945
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Michael Dürig
As mentioned in [1] scripts (which compile to byte code) should not use the
class loader for loading class files to resolve external symbols. Class loaders
are designed to load binary representations of classes into the JVM at runtime.
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.
I faced this issue when I implemented support for Scala. To work around it I
implemented a (Scala specific) file system abstraction on top of Felix's
bundles. While this works ATM, the approach might not be too stable since it
partially relies on implementation details of the underlying classloaders.
Since other scripting languages have the same problem (i.e. JSP AFAIK) I
suggest to factor the hacks into a separate ClassReader service. Scripts can
then use this at compile time to resolve external symbols.
[1] http://sling.markmail.org/message/ly3yhlmqufpugjly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
