Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D49AF83.5070401@christopherschultz.net>
Date: Wed, 02 Feb 2011 14:24:51 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Potential improvements to JspC
References: <4D48C64A.3000107@christopherschultz.net>
 <4D4944B2.6000109@apache.org>
In-Reply-To: <4D4944B2.6000109@apache.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig110A388F545C2D2E42738493"

--------------enig110A388F545C2D2E42738493
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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 privat=
e
>> 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).
>=20
> 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 weba=
pp.

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 a=
s
>> 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 semant=
ics.
>>
>> 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.
>=20
> 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=3D"${catalina.home}/../../build-jspc.xml"
         target=3D"jspc"
         inheritRefs=3D"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


--------------enig110A388F545C2D2E42738493
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Jr4MACgkQ9CaO5/Lv0PAo6QCdF4jNSsoFo+I1Qn3/9m7T8Ijk
4SMAoKeg7K0HIAF6yyvhza1RtnzZFFOj
=r9Y9
-----END PGP SIGNATURE-----

--------------enig110A388F545C2D2E42738493--