[
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.
