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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
