> Hmm... do you have complete control over the version of Tomcat that your > clients use?
Unfortunately, we do not have complete control over this. > 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. > ...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). > My recommendation would be to stick with a single monolithic web.xml... Thanks for the recommendation, but I guess it's moot now. Y'all have all been a lot of help. Thanks! Nick -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, March 12, 2012 9:48 PM To: Tomcat Users List Subject: Re: Precompile JSPs, avoid thousands of servlets? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick, On 3/12/12 4:43 PM, Nick Williams wrote: > We maintain a very large application, with somewhere around 2,000 JSP > files (in addition to ~250,000 lines of pure Java). We have decided it > is about time we ship our application with precompiled JSP files. Hmm... do you have complete control over the version of Tomcat that your clients use? > Our first challenge is that we support Tomcat, GlassFish, WebLogic and > WebSphere, so our JSPs have to be precompiled in such a way that they > will run in any of those web containers. We’ll overcome that challenge > I’m sure; if we have to include some extra libraries, we’ll make it > work. You are toast, as far as Tomcat's precompiler is concerned. The JSP compiler uses Tomcat-specific classes and they are not part of any public API (that is, not stable) so they are very sensitive to the exact version of Tomcat -- sometimes down to the point release (like 7.0.22 and 7.0.23 might be incompatible). My recommendation would be to allow your webapp to be precompiled at (or, rather, immediately before) deploy-time by providing different procedures (maybe ant tasks?) for each container. > Our second challenge is the 11,500-line web.xml file that results > from this process. I understand that Ant does a lot of the hard work > for me, but a web.xml file this large bothers me, even if I don’t have > to look at it during every day development. What’s more, we’re > actually trying to *move away* from having a web.xml file (of any real > substance) and using new Servlet 3.0 features. Note that there are glaring problems with web-fragments including questions about precedence in the face of conflicts for things like overlapping url-patterns, etc. My recommendation would be to stick with a single monolithic web.xml except in cases where you have a definite isolated chunk of features that can be encapsulated into a separate JAR file. > I could swear I saw an example a while ago (while searching Google, of > course) of a web.xml file with a single servlet that responded to > requests for ALL JSPs that had be precompiled, but I can’t find it > anywhere anymore. I’m sure I *could* write my own servlet to > accomplish this, but I’d sure like to use something existing that > already has common usage. Maybe the "invoker" servlet? I'm not entirely sure if I'm kidding, actually. > Does anyone have any ideas? Perhaps JSP isn't the best solution for you... how much dynamic-ness do you need in all these content-generating files? Maybe another technology (Freemarker? I don't think Velocity has a precompiler...) would meet you needs better than JSP, though switching content-generation frameworks isn't a task I would wish on a bitter enemy). - -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/ iEYEARECAAYFAk9etWwACgkQ9CaO5/Lv0PBFMwCgoiB1f1TERHAwtEaLm+zgBq2X MQEAniSMx+hMCqTUuuIev1Ruehn0DK3x =AbQf -----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
