tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Jasper improvements
Date Thu, 27 Jun 2013 03:35:02 GMT
On Jun 26, 2013, at 12:10 PM, Nick Williams <> wrote:

> On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:
>> On Jun 26, 2013, at 7:49 AM, Christopher Schultz <>
>>> Jeremy,
>>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>>> <> 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). 
>>> 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
>> 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:
For additional commands, e-mail:

View raw message