sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SLING-6) Run JSPs located in bundles
Date Fri, 21 Sep 2007 12:12:50 GMT

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

Felix Meschberger commented on SLING-6:
---------------------------------------

Added Component Adapter functionality to adapt Servlets registered as services to Component
instances, which are
in turn registered as services, too.

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


Mime
View raw message