[
https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719505#action_12719505
]
Michael Dürig commented on SLING-1007:
--------------------------------------
I think it is a good idea to isolate script engine implementations from the
class loader internals. However as mentioned in [1] and [2], I think the
proposed approach does not go far enough. Scripts which have a compile step
(i.e. JSP and many others) need to resolve symbols. Doing this against a class
loader is brittle.
Java 1.6 introduces JavaFileManager [3] for compilation. Something along these
lines is what I think is needed for scripting in Sling.
[1] http://sling.markmail.org/message/ly3yhlmqufpugjly
[2] https://issues.apache.org/jira/browse/SLING-945
[3] http://java.sun.com/javase/6/docs/api/javax/tools/JavaFileManager.html
> Implement helper classloader
> ----------------------------
>
> Key: SLING-1007
> URL: https://issues.apache.org/jira/browse/SLING-1007
> Project: Sling
> Issue Type: New Feature
> Components: Commons OSGi
> Affects Versions: Commons OSGi 2.0.4
> Reporter: Felix Meschberger
>
> Currently we require the ScriptEngine[Factory] implementation bundles to
> create bundle header
> DynamicImport-Package: *
> to be able to access anything from the scripts since scripts are executed in
> the class loader of the script engine bundle.
> The downside of running the scripts in the class loader of the script engine
> bundle and using this global dynamic import are:
> * scripts see internal classes of the script engine bundle
> * scripts engine bundles must provide for classes for the scripts
> * whenever a wire has been created for a script and the providing bundle is
> updated or uninstalled, the script engine bundle is also cycled.
> A better approach might be to provide a ClassLoader implementation which
> behind the scenes manages access to packages exported by the bundles
> installed in the system. I would imagine such an implementation along the
> following lines:
> * Uses PackageAdmin to find a bundle providing the required class
> * Copes with bundles being updated or uninstalled
> Maybe coping with bundles being updated or uninstalled requires a two level
> approach: a fronend class loader which answers the class and resource
> accesses by relaying to a backend class loader. The back end classloader does
> the hardwork of loading classes and resources by querying bundles. Whenever a
> bundle is updated or uninstalled the backend classloader gets replaced. A
> similar approach has been chosen for the Repository ClassLoader in the
> jcr/classloader bundle.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
