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 somewhere else if it's more appropriate.
Thanks,
-chris
signature.asc
Description: OpenPGP digital signature
