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
signature.asc
Description: OpenPGP digital signature
