DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40177>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40177 ------- Additional Comments From [EMAIL PROTECTED] 2006-12-27 11:43 ------- Thanks Yoav. > I think Valves are largely out-dated and should be phased out in favor > or portable solutions where possible. I agree with that, but even if 80% or 90% of Valves are better off as Filters, some still aren't. As a developer I have found many cases over the years where I needed to write code that could not be part of a webapp, or that had to use Tomcat's code to do something. Sometimes (rarely, but sometimes) the code has to run as part of Tomcat, and Valves are better documented at this point than <Listener>s are. Since it's not a servlet, nor a Filter, we know that it's not portable to other servlet containers. But, if your company has already decided to use Tomcat, this is okay. Not much code needs to go into a Valve, usually. And while debugging a webapp that is already packaged, and/or already deployed, being able to just add a line or two to server.xml to enable, say, RequestDumperValve (which already exists in Tomcat, ready to run) helps quite a bit because it is a quick way to investigate a bug. This allows us to skip compiling a Filter, installing the class file somewhere, plus we'd have to add both a <filter> block and a <filter-mapping> block to the webapp's web.xml for it. This makes the Valve more convenient in some situations. I wish Tomcat came with more useful Valve tools like this one, not less. I realize that Valves existed first, and that Filters followed. Tomcat could completely drop support for Valves and stay servlet compliant, however it would take away a useful, helpful feature of Tomcat that people do use at times. Thanks again. :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
