Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: unknown ~allmx (nike.apache.org: encountered unrecognized
 mechanism during SPF processing of domain of
 nicholas.williams@puresafety.com)
From: Nick Williams <nicholas.williams@puresafety.com>
References: <4eda3d401cf06e1b22c0d27077b2d2c9@mail.gmail.com>
 <4F5EB56D.2000206@christopherschultz.net>
 <f62de6a5e3059cac025665fae09776fa@mail.gmail.com>
 <4F623182.9000900@christopherschultz.net>
In-Reply-To: <4F623182.9000900@christopherschultz.net>
MIME-Version: 1.0
Thread-Index: Ac0C14jNSeY9OISJREWIejIpMx3gewAAMr3Q
Date: Thu, 15 Mar 2012 13:29:01 -0500
Message-ID: <47773497d8fd060ea33b816e7d3ee0d1@mail.gmail.com>
Subject: RE: Precompile JSPs, avoid thousands of servlets?
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

> It seems reasonable that Jasper could be separated from the core of
> Tomcat.

We may consider attempting integrating Jasper into our product at a later
date to see if that works. Not in this version of the product, however.

> Are you simply trying to reduce the first-access time of each JSP?

The performance improvement is always nice, but irrelevant. That can be
achieved with startup compilation. The bigger issue is making sure that all
of our JSPs compile. We can compile them at build time, but that only
guarantees they'll compile for that particular version of that particular
server. At one point, we had two JSPs that would compile in Tomcat
5.5.26-5.5.33 and Tomcat 6.0.20-6.0.32, but not Tomcat 5.5 < 5.5.26, not
Tomcat 6 > 6.0.32, and not Tomcat 7. We have since fixed this issue and are
trying to bring our JSPs to a more stable state.

(We didn't build this product from the ground up, by the way, just in case
you were wondering. We acquired it from a single developer who had written
all 1.1 million lines of code by himself, never shared the details of the
code with anyone else, never used any 3rd-party frameworks, never used any
design patterns, and had ported (read: not re-written) the project from
Pascal to C++/MFC to Java/Java EE over the course of 20 years.)

N

-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Thursday, March 15, 2012 1:14 PM
To: Tomcat Users List
Subject: Re: Precompile JSPs, avoid thousands of servlets?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick,

On 3/15/12 1:21 PM, Nick Williams wrote:
>> Hmm... do you have complete control over the version of Tomcat that
>> your clients use?
>
> Unfortunately, we do not have complete control over this.

This doesn't look good for you :(

>> The JSP compiler uses Tomcat-specific classes and they are not part
>> of any public API...
>
> Yea, I just looked at the sources for the compiled JSPs and see that
> they're full of references to proprietary Tomcat classes.
> Looks like this is the case no matter which App Server I compile the
> JSPs with ... they end up full of classes from that App Server.
> I guess that makes sense, what with Tag Pooling and everything else.

Exactly: compiled JSPs are more than just raw scriptlets and tag-source
placed into a .java file and compiled. Since the JSP API defines mostly
interfaces and leaves it up to the containers to implement, this is
necessarily the case. There isn't even a standard API for launching a JSP
(other than calling "service"), though I'm sure everyone's implementation
looks basically the same. The fact is that each JSP is going to need a bunch
of support code that simply must come from the container.

There is another possibility: tear-out Jasper from Tomcat and write your own
JSPServlet that you map to *.jsp in your own webapp. It will probably be a
bunch of work, and you'll either have to keep it in sync with the Tomcat
sources or risk getting stale as bugs are fixed and improvements are made.

The advantage, though, is that you could package it with your webapp and the
it doesn't matter what container the client uses: the JSPs will run Jasper
no matter what.

I don't know how hard that would be -- I've never tried it :)

It seems reasonable that Jasper could be separated from the core of Tomcat.
I wonder if anyone else would be interested in such a clean separation.

>> ...though switching content-generation frameworks isn't a task I
>> would wish on a bitter enemy.
>
> Agreed. I wouldn't either.
>
> At this point, it looks like we're going to have to stick to shipping
> the raw JSP files in the application and having them be compiled by
> the container (either at startup or runtime ... one way or another).

There are several ways to trigger compilation at start up (or immediately
thereafter). Are you simply trying to reduce the first-access time of each
JSP? Or is this a solution looking for a real-world problem?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9iMYIACgkQ9CaO5/Lv0PAXOwCeP9hcYtRyOjM2HvCy9KqetMOG
NBcAoKCPHBlNwovMEOw/o4ejU/s+SpML
=arEm
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org