Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <4D4944B2.6000109@apache.org>
Date: Wed, 02 Feb 2011 11:49:06 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Potential improvements to JspC
References: <4D48C64A.3000107@christopherschultz.net>
In-Reply-To: <4D48C64A.3000107@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02/02/2011 02:49, Christopher Schultz wrote:
> All,
> 
> I'm working on getting JspC to create a .jar file that contains all the
> compiled JSPs as well as a META-INF/web-fragment.xml file for easy drop
> into a webapp with no WEB-INF/web.xml modifications in a 3.0-spec webapp.
> 
> At this point, I have it working with a simple patch to
> LocalStrings.properties and a set of 3 new ant targets.
> 
> Here's the problem: it has some environmental requirements that I don't
> like. I'd like to fix some of them and so I'd like kick-around a few ideas.
> 
> First, the JspC task requires that your entire webapp essentially be in
> webapp form before it can really work properly. Specifically, you need
> to set "uriroot" to something that contains a WEB-INF/web.xml file as
> well as the source JSPs and any dependent taglib TLDs in WEB-INF/lib.
> 
> That may not seem like a big deal, but I happen to have my directory
> structure laid out in a way that doesn't fit that profile: I have my
> .jsps in a "web" directory, my libraries in a "lib" directory, and my
> web.xml in a "conf" directory. These items are only brought together at
> the last minute using a <war> task. Thus, it's not particularly
> convenient for me to build the WAR file, then expand it, then run the
> JSP precompiler, then /re-war/ the whole webapp.
> 
> It would be much nicer if I could specify, on the command-line (or via a
> the ant task, which is how I'm doing it, not) the locations of these items.
> 
> I would like to update JspC to accept some new settings in lieu of uriroot:
> 
> jspSourceDir
> jspClasspath
> webXml
> 
> The "webXml" parameter name isn't going to work, as that's already used
> for the location of the web.xml file that will be generated during the
> compilation process. I'm open to suggestions for what to name this
> parameter.

I'm not so sure this needs to change. webXml has special handling. It we
separate webXml (source) and webXmlFragment (destination) then I think
things should be OK.

> There is already a "classpath" setting in JspC.java, but it is not
> accessible via ant for some reason. It's also used to compile the .java
> files into .class files (or so the documentation says). I'd like to make
> this settable via ant properties like <jasper><classpath ...
> /></jasper>.
+1

> It might make sense to use this classpath to also search
> for TLDs, etc.

+1

> but we might also want a jspClasspath to be separate for
> flexibility.

I don't think we need this.

> Finally, the jspSourceDir could be the root of where all JSPs are located.
> 
> All of these settings could be set automagically when using the uriroot
> setting, so these changes should be backward compatible and not too
> tough to build.

+1

> Second, there's no way for an outside process (like JspC for instance)
> to determine the webapp spec version. The JspConfig class has a private
> getVersion method that uses private data and returns a spec version
> number. I'd like to make this information available to outside code.
> Specifically, I'd like JspC to be able to check the version of the
> webapp to determine if the generated web.xml fragment should have the
> servlet 3.0 header and footer, or no header and footer (as is the
> current behavior).

I'd add a genWebXmlFragment (or similar) that if set tries to generate a
Servlet 3.0 fragment and throws an error if the source isn't a 3.0 webapp.

> I'd like to make the compiler spec-version-aware because, though
> precompiled JSPs must be precompiled with the same version of Tomcat as
> will be used in deployment, there's no guarantee that all precompiled
> JSPs will be running in 3.0-spec-version webapps. For those cases, I
> don't want to generate a web-fragment.xml with 3.0-spec-version semantics.
>
> Along these lines, I might like to add a setting in JspC that
> specifically requests 3.0-spec-version semantics (such as emitting a
> 3.0-spec-version web-fragment.xml file) and will cause an error if the
> webapp's web.xml does not specify that same (or higher) version.

See previous comment.

> All of the above changes will require some changes to JspConfig,
> JspCServletContext, and probably some other associated changes to allow
> the synthesis of several disparate source locations (.jsp, lib, and
> web.xml source) to look like a legitimate webapp.
> 
> I'd appreciate any comments anyone might have on the above, especially
> by anyone who has had intimate dealings with Jasper and JspC.

General direction looks good to me. I'd recommend several incremental
patches where possible to make reviewing simpler.

Mark

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