tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Potential improvements to JspC
Date Wed, 02 Feb 2011 02:49:46 GMT
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.

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>. It might make sense to use this classpath to also search
for TLDs, etc. but we might also want a jspClasspath to be separate for
flexibility.

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.

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 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.

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.

Thanks,
-chris


Mime
View raw message