On Mon, May 17, 2021 at 8:47 PM Mark Thomas <ma...@apache.org> wrote:
> Hi all,
>
> I am looking at some of the optimizations requested in [1]
>
> One of the examples is show below. Code like this is used when the JSP
> calls a tag.
>
>
> private boolean _jspx_meth_mytag_005fhelloWorld_005f0(
> jakarta.servlet.jsp.PageContext _jspx_page_context)
> throws java.lang.Throwable {
> jakarta.servlet.jsp.PageContext pageContext = _jspx_page_context;
> // mytag:helloWorld
> ....
> }
>
> The question is, can the generated code above be changed to something
> like this:
>
> private boolean _jspx_meth_mytag_005fhelloWorld_005f0(
> final jakarta.servlet.jsp.PageContext pageContext)
> throws java.lang.Throwable {
> // mytag:helloWorld
> ....
> }
>
>
> I am assuming that the aliasing of _jspx_page_context to pageContext is
> so that _jspx_page_context always references the original even if the
> tag decides to do something like:
>
> pageContext = new MyCustomPageContextImpl();
>
> The question is, is behaviour like this allowed?
>
> I can't see anything in the spec that disallows this.
>
> I don't think the aliasing is a defence against malicious apps as it is
> only the implicit objects that are protected this way. Internal objects
> (those name _jsp*) are unprotected.
>
> Given that the original authors (who were on the JSP EG at the time)
> added this aliasing for the implicit objects, it looks like the
> intention was to allow applications to manipulate/replace the implicit
> objects if they wish - without breaking Jasper.
>
> If the above assumptions are correct, what do we want to do about [1]?
> The aliasing is often unnecessary but will sometimes be essential. Do we
> reject this optimization request? Do we add a configuration option? Do
> we try and make this aspect of the code generation pluggable somehow?
> Something else?
>
> Thoughts very welcome.
>
Well, although I do see how this makes the generated code a little bit
smaller, this is a rather small optimization (even with 1000s of
occurrences). Since you've identified a risk, and it seems correct to me
(I'm almost certain this was on purpose and because the idea is not
forbidden in the specification), I would say we should skip that one.
Rémy
>
> Mark
>
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
