Hi!
Thanks for your answer. I use url-rewrite magic servlet (analog to
apache mod_rewrite), so I have the same "on the fly" rewrite
functionality (the rewrite-rules.xml is checked every minute or somth).
I do all the request/response stuff in Tomcat as long it's relevant
and a part of the system I don't want to move a part of functionality
to Apache, I prefer having "all-in-one" solution (this is why I use
Quartz for scheduled tasks and not some chron-jobs).
And I can't see the connection, why my code have to be perfectly bug
free? I mean, if I do have bugs Apache wont come and save my ass right? :))
Cheers,
Danny
Mark Hagger wrote:
This issue is discussed endlessly as far as I can see, both camps argue
very well for their case....
However, my take from personal experience is that its very "handy" to
have Apache in front, because it gives you a lot of scope to do little
fixes and tweaks to odd users causing problems without any service
downtime. For example you can pretty much add Apache Rewrite rules all
over the shop to fix up little issues without having to actually restart
any servers, (just an Apache SIGHUP, or reload).
You can also fiddle with the various request headers, response headers,
logging of request, response headers, with no impact on the back-end
tomcat layer and its webapps.
Of course there is the load balancer issue as well, if you
require/desire to have sticky sessions.
Obviously if your code is perfect and bug free and users are all
perfect, and sticky sessions are not required then then perhaps
tomcat-only is the solution. Although I've yet to meet an author of bug
free code.
Thats my opinion anyway.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
