[jira] Updated: (SLING-6) Run JSPs located in bundles

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] Updated: (SLING-6) Run JSPs located in bundles

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/SLING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated SLING-6:

      Component/s: Plugin
    Fix Version/s: 2.0.0

- Adding Plugin component as the compilation step is implemented in the maven-jspc-plugin
- tagging for version 2.0.0

> Run JSPs located in bundles
> ---------------------------
>                 Key: SLING-6
>                 URL: https://issues.apache.org/jira/browse/SLING-6
>             Project: Sling
>          Issue Type: New Feature
>          Components: JSP, Plugin
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: 2.0.0
> ------- Original Request By Carsten Ziegeler
> JSPs seem to not get the same classloader as the bundle they are contained in. Therefore they can't access any private (not exported) classes from this bundle
> which would require to export private classes.
> ------- Additional Comments From Felix Meschberger
> This problem cannot be solved because it is caused by the design.
> Though the JSPs come from the bundle (as they are introduced to the system as part of the bundle), the live and act inside the repository, which has another scope. The repository has no way of deciding, which bundle a JSP belongs to and to which bundle, a JSP should have access to non-exported classes.
> Hence JSPs only have access to exported classes.
> Now, there would be solutions to this issue, of course:
>   (1) Leave the JSPs in the bundle and fix compiling bundles from within JSPs
>       and have them run in the context of the bundle they come from using the
>       bundle's class loader
>   (2) Pack the respective required classes in libraries, which are also deployed to
>       the repository. As such, they would be available to ALL repository-based
>       JSPs but on the other hand would be required to only use exported packages.
> Both solutions are viable for me and have the pros and cons:
>    + Repository based may easily be fixed
>    - Repository based looses control of what is actually installed
>    + Bundle based remains with its bundle and will be updated when the bundle
>      is updated
>    - Repository based will not be updated on bundle update as it is content and
>      content is never updated if already existing !
> All-in-all, I currently tend to more like the bundle-based solution for JSPs
> distributed with bundles.
> What do you think ?
> ------- Additional Comments From Carsten Ziegeler
> Yes, I think the bundle-based solution makes more sense, apart from fixing the classloading problem (I don't want to expose my internal classes to everyone),
> it solves the update problem: updating a bundle with jsps, currently does not update the jsps itself obviously.
> I think we can live with the cons.
> ------- Additional Comments From Felix Meschberger
> Currently JSPs must be located in the repository for the JSP Script handler to be able to run them. Functionality should be added to the JSP Script handler to
> compile and run bundle based JSPs. Furthermore, these JSPs should be compiled and run in the context of the bundle's class loader.
> In fact, while being at it, the Scripting core might provide some degree of support for bundle-based scripts at large. So also future script handlers (e.g. ECMA, JSR-223) might also benefit from this.
> ------- Additional Comments From Felix Meschberger
> Instead of having the Sling Runtime compile the JSPs contained in the bundles it would probably be better to have the bundle build tool compile the JSPs into
> class files to be packaged with the bundle. These could then easily be executed as any other Java Class.
> We need some integration tooling though for this case:
>    -> Define Components referring to the JSPs
>    -> Access the classes
>    -> Provide context for the execution.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.