You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/06/15 08:52:07 UTC
[jira] Created: (SLING-1007) Implement helper classloader
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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719530#action_12719530 ]
Felix Meschberger commented on SLING-1007:
------------------------------------------
> Take a look at the JSP compiler then. It has exactly the same problem.
Maybe yes, when looking from inside. But since we are using Jasper (with slight modifications) we don't have an issue there.
> 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.
[jira] Assigned: (SLING-1007) Implement helper classloader
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned SLING-1007:
---------------------------------------
Assignee: Carsten Ziegeler
> 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
> Assignee: Carsten Ziegeler
>
> 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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721113#action_12721113 ]
Carsten Ziegeler commented on SLING-1007:
-----------------------------------------
I'll start with the original issue and when we've finished that we can have a look at the other use case.
> 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
> Assignee: Carsten Ziegeler
>
> 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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720184#action_12720184 ]
Michael Dürig commented on SLING-1007:
--------------------------------------
I don't think so. If Sling wants to provide a clean interface for script engine implementers it should not abuse the class loader for this. The reason why we 'don't have an issue' with Jasper is because Jasper already implements the obscure tricks which are necessary to do compile time symbol resolution against a class loader. So we are just lucky here. The current approach forces each implementer of a new script engine to resort to the same obscure tricks over and over again.
> 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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719527#action_12719527 ]
Michael Dürig commented on SLING-1007:
--------------------------------------
> As I said before this is not a primary issue for now (the only scripting language I
> know of with similar problems is Scala).
Take a look at the JSP compiler then. It has exactly the same problem.
> 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.
[jira] Commented: (SLING-1007) Implement helper classloader
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719509#action_12719509 ]
Felix Meschberger commented on SLING-1007:
------------------------------------------
As I said before this is not a primary issue for now (the only scripting language I know of with similar problems is Scala).
For this concrete issue, it is completely out of scope and should not be considered right now. If we later think we have to broaden the issue/solution, we still can do that. For now a "simple" classloader is what we need.
> 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.