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=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Jasper improvements/XML handling
From: Jeremy Boynes <jboynes@apache.org>
In-Reply-To: <F94161FF-F640-409A-9D09-BD086F6BEDD7@apache.org>
Date: Sun, 7 Jul 2013 22:38:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CD26D21-C2F5-4F1D-AF51-A2868D407829@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>
To: "Tomcat Developers List" <dev@tomcat.apache.org>

On Jun 25, 2013, at 10:44 PM, Jeremy Boynes <jboynes@apache.org> wrote:

> 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 started on this and ended up with two patches that are converging. For =
55166 (which started out somewhere different), I have a patch to update =
local entity handling in Catalina's XML parsing; for 53737, I started to =
have Jasper's translator rely only on the ServletContext and not need to =
parse merged web.xml XML passed as a ServletContext attribute. These are =
converging in a few areas.

Jasper's descriptor parser (used for web.xml and TLDs) can only validate =
DTD-based documents. I opened 55212 about adding it. Such a fix could =
benefit from using the same resolver and cached copies that Catalina =
does. This is less of an issue if Jasper uses the ServletContext as it =
could rely on the container to parse/validate web.xml. It would still be =
needed if we wanted JspC to validate files standalone but there is a =
separate ant task that can do that.

Another area of convergence is in parsing TLDs: currently both Catalina =
and Jasper do it, differently. I believe Catalina only reads them to =
detect the Listeners they define and if that's the case we could perhaps =
add a SCI to Jasper that handled all TLD functionality including =
registering the listeners programmatically (at least that's what Servlet =
8.3 implies) . That would remove Catalina's dependency on =
web-jsptaglibrary*.xsd and on TLD-related classes. To support validation =
though we would need to add the XSD-based validation in Jasper.

Finally, Jasper parses these documents first into DOM and the into its =
own version based on TreeNode (this is separate from the parse tree used =
for actual JSPs). Jasper already depends on tomcat-util for the =
JarScanner so could potentially use Digester for this in the same way =
Catalina does. It would simplify the fragment merge logic in JspC if it =
could reuse what was in Catalina's WebXml (something I'm hacking around =
in 53737 right now).  Alternatively, we could still eliminate the =
intermediary DOM and TreeNode forms and use SAX or StAX to parse =
directly into Jasper's objects - especially for TLDs where it is using =
the spec's classes (TagLibraryInfo and TagInfo) as the model.

I'm planning on merging these two patches and pressing on with a =
converged solution, but probably won't be able to do much until next =
weekend.

Cheers
Jeremy=

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