Re: Potential improvements to JspC
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 jasperclasspath ... //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
Re: Potential improvements to JspC
Mark,
On 2/2/2011 6:49 AM, Mark Thomas wrote:
On 02/02/2011 02:49, Christopher Schultz wrote:
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.
The current webXml setting specifies the target for a merged-web.xml
file that JspC will generate automatically by merging the existing
webapp's web.xml and the servlet definitions generated during the
compilation process.
Are you suggesting that we leave that setting alone (I agree) and create
something new like sourceWebXml? I like that. Be aware that
webXmlFragment (destination) already exists. See below.
but we might also want a jspClasspath to be separate for
flexibility.
I don't think we need this.
Okay. It was just a thought, and it's easy to make it backward
compatible so that a user only uses if if they /really/ want to.
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.
There's been a setting, webXmlFragment, that already does this, except
that it generates a snip of non-well-formed XML that the user is
expected to integrate into web.xml themselves.
I see us having several options, here:
1. Change the behavior of the webXmlFragment setting so that it always
generates a fragment that has a header and footer that match the
original web.xml DOCTYPE/xmlns. This would break backward
compatibility, as users would have to strip-out these header and
footer. For a manual process, this isn't a big deal. For automated
processes, it would probably be a real pain in the neck. On the other
hand, we don't end up with a bunch of settings that are confusingly
similar (webXmlFragment(exists), webXml(exists),
genWebXmlFragment(new), etc.).
2. Create a new setting that implies a 30-spec-version and throw an
error if the webapp isn't 3.0-spec-version. This has the unfortunate
consequence that we pollute our settings namespace with yet another
web.xml-related setting (see #1 above).
3. Hmm. I thought there were three things when I started. I can't think
of another one. shrug
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.
Any reason not to allow client code to ask JspConfig what the version of
the webapp is, though? This can certainly be one of those incremental
changes. Note that having JspC complain if a 3.0-spec-version feature is
requested (specifically, a 3.0-spec-compliant web-fragment.xml) this
change will be necessary. Otherwise, there's no convenient way to detect
the spec version of the webapp.
General direction looks good to me. I'd recommend several incremental
patches where possible to make reviewing simpler.
Agreed.
One last thing: I have a separate Ant build script called build-jspc.xml
that I've been working in. The idea is that you do an ant call from
within your own webapp's build.xml after setting up all the settings.
This would allow people to use a pre-build set of Ant targets instead of
copy/pasting from the JspC HOWTO web page.
Basically, the instructions would be reduced to something like this:
1. Set the following settings: (list them)
2. Add this to your ant script in your JspC target:
ant antfile=${catalina.home}/../../build-jspc.xml
target=jspc
inheritRefs=true
/
Any objections to including such a separate script in the Tomcat tree
somewhere? Right now, I have it at the top-level, but I'm open to
putting it
Potential improvements to JspC
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 jasperclasspath ... //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
