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