Re: Jasper improvements

[Jeremy Boynes <jb...@apache.org>]

On Jun 26, 2013, at 7:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:

> Jeremy,
> 
> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>> <ni...@nicholaswilliams.net> wrote:
>>> 
>>> Okay. One of many reasons I ask is that I still have it on my to-do
>>> to make some improvements on the JSP compiler to support things
>>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I
>>> don't know how much the EL changes might affect this JSP
>>> compilation (hopefully it's fairly decoupled), and I'd like that to
>>> not seriously hinder any effort to back-port my improvements to
>>> Tomcat 7. I'm wondering if this needs to move higher on my list and
>>> get in before the EL changes. Any insight?
>> 
>> I have been thinking about improvements to Jasper as well around
>> better support for Servlet 3.0 concepts. One area would be decoupling
>> it from Tomcat, bootstrapping using an SCI as hinted in
>> ContextConfig. I'd also be interested in improving the Ant task as
>> well, such as support for pre-compiling a separate package that would
>> be treated as a web fragment (including web.xml-less pre-compilation,
>> generating a web-fragment.xml rather than a web.xml snippet or
>> potentially eliminating the XML entirely if the generated code can be
>> annotated with @WebServlet). 
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50234
> 
> I tried some forays into this a few years ago, but got stuck in the
> confusion of how everything works together. I wanted to do something
> simple like get the web-app's spec-version number, but could not figure
> out how to do it.

I find usage and implementation very confusing as well - an example being things that can be configured on the Task vs. init-params for the JSP servlet vs. things set via system properties. A challenge here is that cleaning it up would likely warrant incompatible changes so would be out for 7.x but potentially possible for 8.x - I'd be interested in what people think about a major refactor that allowed incompatible changes (assuming they were justified not arbitrary).

You wrote in the bug that "annotation's don't make sense" - could you clarify that? I was thinking that we could have Jasper add @WebServlet("/foo.jsp") to the class generated for "foo.jsp" and then that would be picked up by a container as part of its normal scan. We could also have an SCI @HandlesTypes(JspPage.class) and then register the JSP servlets itself but two issues come to mind:
1) the need for metadata that duplicates what the normal servlet annotations could convey
2) avoiding conflicts with classes that are bound via jsp-property-group or servlet-mapping elements in XML descriptors

What happens to a fragment compiled a build-time whose properties differ from those in the final runtime (for example, due to settings resulting from a merged web.xml)? One option would be to say that the build process had simply converted all the JSPs into a jar-full of Servlets and that they should be deployed as such; if the user wants them treated as JSPs they should be packaged as such into META-INF/resources.

How should we control pre-compile on deploy? The spec already supports if the web.xml contains a <servlet> entry with a <jsp-file> and <load-on-startup> but that requires defining a entry for every individual JSP ("jsp-file element contains the full path to *a* JSP file" on pp 14-160) which is a pain. We could embed an Ant task in a configuration file (e.g. META-INF/jasper.xml) but that adds a dependency on Ant and seems like overkill. Alternatively we can have the SCI read the configuration file and do the necessary.

If we go the SCI route, we could also define a JspConfiguration annotation or interface that a user could place on a class they want to handle initialization. The SCI could @HandlesTypes that, calling it to handle user-provided initialization. We could expose the translator and compiler interfaces so it can handle pre-compilation; we could refactor the JSPServlet to use them in the same way.

Cheers
Jeremy

BTW, can't we use ServletContext#getEffectiveMajorVersion() to determine the spec-version number?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Jasper improvements

[Jeremy Boynes <jb...@apache.org>]

On Jun 26, 2013, at 12:58 PM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> On 6/26/13 2:57 PM, Jeremy Boynes wrote:
>> 
>> You wrote in the bug that "annotation's don't make sense" - could you
>> clarify that?
> 
> Yes: I was thinking that generating classes that used annotations would
> be a good idea. In retrospect, I don't believe it would be a good idea
> -- at least not by default. Since we are generating a web-fragment,
> there's no need to use annotations. We could also cheat and not use a
> web-fragment and instead use annotations.
> 
>> I was thinking that we could have Jasper add @WebServlet("/foo.jsp")
>> to the class generated for "foo.jsp" and then that would be picked up
>> by a container as part of its normal scan.
> 
> While that is possible, I see no reason not to explicitly-map the
> servlets individually in a web-fragment. The user can then easily edit
> the single output file (web-fragment.xml) and modify it if necessary.
> For instance, maybe some JSPs shouldn't be called directly.

Perhaps this should be user-configurable (option to generate a web-fragment.xml or annotations on the generated classes)?

>> BTW, can't we use ServletContext#getEffectiveMajorVersion() to
>> determine the spec-version number?
> 
> Sure we can, but JspC doesn't provide a ServletContext...

It kind of does:
  http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspCServletContext.java?view=markup
but it also has its own versions of WebXml and JspConfig, as well as the JspCompilationContext and JspRuntimeContext. This is one of the areas I found confusing :)

As I was proposing in my other post, if we could make the compilation process driven entirely off a ServletContext we can separate the JSP processing from the context setup which should simplify its implementation. JspC would then handle setup of a build-time JspCServletContext in the same way Catalina sets up the runtime ServletContext.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Jasper improvements

[Christopher Schultz <ch...@christopherschultz.net>]

Jeremy,

On 6/26/13 2:57 PM, Jeremy Boynes wrote:
> On Jun 26, 2013, at 7:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 
>> Jeremy,
>>
>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>> <ni...@nicholaswilliams.net> wrote:
>>>>
>>>> Okay. One of many reasons I ask is that I still have it on my to-do
>>>> to make some improvements on the JSP compiler to support things
>>>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I
>>>> don't know how much the EL changes might affect this JSP
>>>> compilation (hopefully it's fairly decoupled), and I'd like that to
>>>> not seriously hinder any effort to back-port my improvements to
>>>> Tomcat 7. I'm wondering if this needs to move higher on my list and
>>>> get in before the EL changes. Any insight?
>>>
>>> I have been thinking about improvements to Jasper as well around
>>> better support for Servlet 3.0 concepts. One area would be decoupling
>>> it from Tomcat, bootstrapping using an SCI as hinted in
>>> ContextConfig. I'd also be interested in improving the Ant task as
>>> well, such as support for pre-compiling a separate package that would
>>> be treated as a web fragment (including web.xml-less pre-compilation,
>>> generating a web-fragment.xml rather than a web.xml snippet or
>>> potentially eliminating the XML entirely if the generated code can be
>>> annotated with @WebServlet). 
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50234
>>
>> I tried some forays into this a few years ago, but got stuck in the
>> confusion of how everything works together. I wanted to do something
>> simple like get the web-app's spec-version number, but could not figure
>> out how to do it.
> 
> I find usage and implementation very confusing as well - an example being things that can be configured on the Task vs. init-params for the JSP servlet vs. things set via system properties. A challenge here is that cleaning it up would likely warrant incompatible changes so would be out for 7.x but potentially possible for 8.x - I'd be interested in what people think about a major refactor that allowed incompatible changes (assuming they were justified not arbitrary).
> 
> You wrote in the bug that "annotation's don't make sense" - could you
> clarify that?

Yes: I was thinking that generating classes that used annotations would
be a good idea. In retrospect, I don't believe it would be a good idea
-- at least not by default. Since we are generating a web-fragment,
there's no need to use annotations. We could also cheat and not use a
web-fragment and instead use annotations.

> I was thinking that we could have Jasper add @WebServlet("/foo.jsp")
> to the class generated for "foo.jsp" and then that would be picked up
> by a container as part of its normal scan.

While that is possible, I see no reason not to explicitly-map the
servlets individually in a web-fragment. The user can then easily edit
the single output file (web-fragment.xml) and modify it if necessary.
For instance, maybe some JSPs shouldn't be called directly.

> BTW, can't we use ServletContext#getEffectiveMajorVersion() to
> determine the spec-version number?

Sure we can, but JspC doesn't provide a ServletContext...

-chris

Re: Jasper improvements

[Jeremy Boynes <jb...@apache.org>]

On Jun 26, 2013, at 12:10 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:

> 
> On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:
> 
>> On Jun 26, 2013, at 7:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> 
>>> Jeremy,
>>> 
>>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>>> <ni...@nicholaswilliams.net> wrote:
>>>>> 
>>>>> Okay. One of many reasons I ask is that I still have it on my to-do
>>>>> to make some improvements on the JSP compiler to support things
>>>>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I
>>>>> don't know how much the EL changes might affect this JSP
>>>>> compilation (hopefully it's fairly decoupled), and I'd like that to
>>>>> not seriously hinder any effort to back-port my improvements to
>>>>> Tomcat 7. I'm wondering if this needs to move higher on my list and
>>>>> get in before the EL changes. Any insight?
>>>> 
>>>> I have been thinking about improvements to Jasper as well around
>>>> better support for Servlet 3.0 concepts. One area would be decoupling
>>>> it from Tomcat, bootstrapping using an SCI as hinted in
>>>> ContextConfig. I'd also be interested in improving the Ant task as
>>>> well, such as support for pre-compiling a separate package that would
>>>> be treated as a web fragment (including web.xml-less pre-compilation,
>>>> generating a web-fragment.xml rather than a web.xml snippet or
>>>> potentially eliminating the XML entirely if the generated code can be
>>>> annotated with @WebServlet). 
>>> 
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50234
>>> 
>>> I tried some forays into this a few years ago, but got stuck in the
>>> confusion of how everything works together. I wanted to do something
>>> simple like get the web-app's spec-version number, but could not figure
>>> out how to do it.
>> 
>> I find usage and implementation very confusing as well - an example being things that can be configured on the Task vs. init-params for the JSP servlet vs. things set via system properties. A challenge here is that cleaning it up would likely warrant incompatible changes so would be out for 7.x but potentially possible for 8.x - I'd be interested in what people think about a major refactor that allowed incompatible changes (assuming they were justified not arbitrary).
>> 
>> You wrote in the bug that "annotation's don't make sense" - could you clarify that? I was thinking that we could have Jasper add @WebServlet("/foo.jsp") to the class generated for "foo.jsp" and then that would be picked up by a container as part of its normal scan. We could also have an SCI @HandlesTypes(JspPage.class) and then register the JSP servlets itself but two issues come to mind:
>> 1) the need for metadata that duplicates what the normal servlet annotations could convey
>> 2) avoiding conflicts with classes that are bound via jsp-property-group or servlet-mapping elements in XML descriptors
>> 
>> What happens to a fragment compiled a build-time whose properties differ from those in the final runtime (for example, due to settings resulting from a merged web.xml)? One option would be to say that the build process had simply converted all the JSPs into a jar-full of Servlets and that they should be deployed as such; if the user wants them treated as JSPs they should be packaged as such into META-INF/resources.
>> 
>> How should we control pre-compile on deploy? The spec already supports if the web.xml contains a <servlet> entry with a <jsp-file> and <load-on-startup> but that requires defining a entry for every individual JSP ("jsp-file element contains the full path to *a* JSP file" on pp 14-160) which is a pain. We could embed an Ant task in a configuration file (e.g. META-INF/jasper.xml) but that adds a dependency on Ant and seems like overkill. Alternatively we can have the SCI read the configuration file and do the necessary.
>> 
>> If we go the SCI route, we could also define a JspConfiguration annotation or interface that a user could place on a class they want to handle initialization. The SCI could @HandlesTypes that, calling it to handle user-provided initialization. We could expose the translator and compiler interfaces so it can handle pre-compilation; we could refactor the JSPServlet to use them in the same way.
> 
> A word of caution: I don't think web.xml-less compilation is possible. web.xml /and/ web-fragment.xml can contain <jsp-config>, which sets up rules surrounding how JSPs are compiled. Before a single JSP in an application can be compiled, the deployment descriptor and all web fragments must be processed and merged so that the JSP configuration can be taken into consideration during compilation. This requires a large portion of the application (you need WEB-INF/web.xml and WEB-INF/lib).

Could we do this with two different modes: one for a fully assembled web application, the other for a standalone JSP web fragment? 

In fully-assembled mode users would assemble their fragments with the JSP source in META-INF/resources and then compilation would happen using the context of the fully assembled application. This is what we have today, only instead of Jasper needing the container to provide a synthetic web.xml as an attribute it gets all of its information from the ServletContext as described in section 8.3 of the spec. All the merging is handled by the ServletContainer and is available through getJspConfigDescriptor().  

When run in this mode outside a container, the setup part of the Ant Task would need to mimic a full ServletContext including the merging etc. which I don't believe it does today (i.e. JspC does not pre-compile JSP resources in web fragment jars, only those in the final webapp). We could potentially reuse that logic from Catalina rather than replicate it.

Standalone JSP web fragment mode on the other hand would allow users to pre-compile JSPs into a library jar that would appear to the assembler/container as one containing Servlets rather than JSPs (described by a web-fragment.xml or @WebServlet annotations). Assembly is different to above as it is happening based on binary classes rather than JSP source. The effect of that is that the provider here is able to set the own JSP settings and not have them impacted by settings of the final assembly. This mimics today's behaviour when JspC is run against a fragment project where it uses the web.xml supplied at build time for that fragment. For this to work we would need to add options to JspC to allow the context to be defined as the fragment source would not itself contain a WEB-INF.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Jasper improvements

[Nick Williams <ni...@nicholaswilliams.net>]

On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:

> On Jun 26, 2013, at 7:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 
>> Jeremy,
>> 
>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>> <ni...@nicholaswilliams.net> wrote:
>>>> 
>>>> Okay. One of many reasons I ask is that I still have it on my to-do
>>>> to make some improvements on the JSP compiler to support things
>>>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I
>>>> don't know how much the EL changes might affect this JSP
>>>> compilation (hopefully it's fairly decoupled), and I'd like that to
>>>> not seriously hinder any effort to back-port my improvements to
>>>> Tomcat 7. I'm wondering if this needs to move higher on my list and
>>>> get in before the EL changes. Any insight?
>>> 
>>> I have been thinking about improvements to Jasper as well around
>>> better support for Servlet 3.0 concepts. One area would be decoupling
>>> it from Tomcat, bootstrapping using an SCI as hinted in
>>> ContextConfig. I'd also be interested in improving the Ant task as
>>> well, such as support for pre-compiling a separate package that would
>>> be treated as a web fragment (including web.xml-less pre-compilation,
>>> generating a web-fragment.xml rather than a web.xml snippet or
>>> potentially eliminating the XML entirely if the generated code can be
>>> annotated with @WebServlet). 
>> 
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50234
>> 
>> I tried some forays into this a few years ago, but got stuck in the
>> confusion of how everything works together. I wanted to do something
>> simple like get the web-app's spec-version number, but could not figure
>> out how to do it.
> 
> I find usage and implementation very confusing as well - an example being things that can be configured on the Task vs. init-params for the JSP servlet vs. things set via system properties. A challenge here is that cleaning it up would likely warrant incompatible changes so would be out for 7.x but potentially possible for 8.x - I'd be interested in what people think about a major refactor that allowed incompatible changes (assuming they were justified not arbitrary).
> 
> You wrote in the bug that "annotation's don't make sense" - could you clarify that? I was thinking that we could have Jasper add @WebServlet("/foo.jsp") to the class generated for "foo.jsp" and then that would be picked up by a container as part of its normal scan. We could also have an SCI @HandlesTypes(JspPage.class) and then register the JSP servlets itself but two issues come to mind:
> 1) the need for metadata that duplicates what the normal servlet annotations could convey
> 2) avoiding conflicts with classes that are bound via jsp-property-group or servlet-mapping elements in XML descriptors
> 
> What happens to a fragment compiled a build-time whose properties differ from those in the final runtime (for example, due to settings resulting from a merged web.xml)? One option would be to say that the build process had simply converted all the JSPs into a jar-full of Servlets and that they should be deployed as such; if the user wants them treated as JSPs they should be packaged as such into META-INF/resources.
> 
> How should we control pre-compile on deploy? The spec already supports if the web.xml contains a <servlet> entry with a <jsp-file> and <load-on-startup> but that requires defining a entry for every individual JSP ("jsp-file element contains the full path to *a* JSP file" on pp 14-160) which is a pain. We could embed an Ant task in a configuration file (e.g. META-INF/jasper.xml) but that adds a dependency on Ant and seems like overkill. Alternatively we can have the SCI read the configuration file and do the necessary.
> 
> If we go the SCI route, we could also define a JspConfiguration annotation or interface that a user could place on a class they want to handle initialization. The SCI could @HandlesTypes that, calling it to handle user-provided initialization. We could expose the translator and compiler interfaces so it can handle pre-compilation; we could refactor the JSPServlet to use them in the same way.

A word of caution: I don't think web.xml-less compilation is possible. web.xml /and/ web-fragment.xml can contain <jsp-config>, which sets up rules surrounding how JSPs are compiled. Before a single JSP in an application can be compiled, the deployment descriptor and all web fragments must be processed and merged so that the JSP configuration can be taken into consideration during compilation. This requires a large portion of the application (you need WEB-INF/web.xml and WEB-INF/lib).

N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org