>> Thanks for the input. I didn't build my own for 2 reasons: 1) don't >> have any cc / gcc on my RHEL linux server - it is used purely for >> production and only have proven stable things on it from the RHEL >> updates. > > Leaving gcc off your production service is a good idea, but I don't buy > your "stability" argument. Red Hat certainly has a stable gcc available > for their distro.
Agreed, but I find that gcc lends you to compile things yourself, which may be more "bleeding-edge" than you want. By keeping gcc off the machine, it forces an admin to download only precompiled RPM apps, usually from a RHEL update server, which means that there aren't any major changes, and we can live happily knowing that the machine wont randomly crash from a poorly pkg'ed or poorly installed applicaiton. >> 2) I was under the impression that it would only work with 2.0.59 >> version of apache - that it had some code in there that would not >> compile / function with 2.0.52. > > You /must/ use the proper major version number (2.0.x versus 2.2.x), but > you can probably use the same .so for many point releases without a > problem. It's always best to have a perfectly-matching shared library, > though; you might find that there was a bug in a version of Apache that > caused an odd linking or something, and you could get bitten by that. I had not realized that. I'll definitely keep that in mind. Thx for the info. >> Our tomcat apps are self-contained (non-exploded) wars, and mapping >> each individual extension becomes a challenge (ie: .jsp, .jspa, jsps, >> .jpg, .js, .....) , so we found it easier just to map the entire >> context. > > Agreed. I didn't realize that you were using Tomcat to serve everything > including static content. You can always do: I use Tomcat to serve everything (including static content) from everything within the war. This allows us to redeploy updated wars without much hassle, not needing to worry about what content is where, and/or if things need to get remapped, updated, etc. I realize that there is prob a slight performance hit having to go through 2 servers instead of one, but it also allows me to keep my java apps pkged up nice and neat in their own locations, and makes automated updates much easier. > If you're going to front Tomcat with Apache httpd, then serving static > content from httpd is more efficient because you don't have to > re-package and forward the request to have Tomcat re-parse everything > and start the process over again. That's more or less what I figured, but we've decided to bite the bullet on that performance hit for the moment. Plus, it also allows me to separate my tomcat server from my httpd server, and their filesystems as well. Perhaps one day we'll move to shared mounted filesystems, but for the moment, we are avoiding the extra configuration that that requires. >> Would going about it in the "opposite" direction be a bad idea? Ie: >> JkMount the entire context and JkUnmount the specific files / >> extensions that you don't want mounted? > > No, that's perfectly acceptable. I just tend to thing about things in > terms of "okay, what do I /want/ Tomcat to serve", rather than the other > way around. But then again, I want httpd to serve my static content and > Tomcat to serve only my servlets. Excellent. Thx again for the help / info! Eric --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
