Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: error (athena.apache.org: local policy)
Sender: Jeremy Boynes <jeremy@boynes.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Jasper improvements
From: Jeremy Boynes <jboynes@apache.org>
In-Reply-To: <51CAFF63.4070502@christopherschultz.net>
Date: Wed, 26 Jun 2013 11:57:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5607670F-0618-4A2B-BD92-25936A42B43B@apache.org>
References: <3729862D-8A29-4F18-BF4F-77BA0710D3B5@nicholaswilliams.net>
 <51B78A5A.1020004@apache.org>
 <12D01606-88EC-4CB0-AAFA-E4B1020F1D69@nicholaswilliams.net>
 <F94161FF-F640-409A-9D09-BD086F6BEDD7@apache.org>
 <51CAFF63.4070502@christopherschultz.net>
To: "Tomcat Developers List" <dev@tomcat.apache.org>

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

> Jeremy,
>=20
> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>> <nicholas@nicholaswilliams.net> wrote:
>>>=20
>>> 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?
>>=20
>> 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).=20
>=20
> https://issues.apache.org/bugzilla/show_bug.cgi?id=3D50234
>=20
> 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