Re: Valves being converted to Filters?
This is my concern as well. Our custom login valve is using values from the form authentication valve that are not accessible in the war file. For example they allow reconstruction of a post request and replacing roles and principals, which I doubt can be done with a filter in a simple way without repeating a lot of code. Even though there is a lot in common, I would like to have access to the tomcat internal data and not be limited to the application level API. Valve cam use HttpServletRequest and response, if you know that you can cast them to an internal class with the full API. In that case it may be safer to just use that class in the method signatures. E - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Wed, 21 Oct 2009 08:11:17 -0700 (PDT) Subject: Re: Valves being converted to Filters? Will there be a way to grab information from the raw request as seen by a Valve today? It's nice to be able to get and set values above (or below, depending on your POV) the servlet API. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valves being converted to Filters?
Eric B. wrote: Mark Thomas ma...@apache.org wrote in message news:200910202047470...@265006334... Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Even without valves, there are lots of other ways to customize the container. You can also specify Filters at the global host level (may also add engine to that list). Really? Does that exist already? So far, the only place I know about where I can configure filters are in the web.xml file(s) - both in the application's web.xml and in the server's global web.xml. Is there another place / manner in which to configure a filter on a per-host basis? Or is this something that is only going to be available in a future release? You can place web.xml.default and context.xml.default files in $CATALINA_BASE/conf/EngineName/HostName/ Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valves being converted to Filters?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/20/2009 9:47 PM, Mark Thomas wrote: Is there a specific reason for this? Portability, reduce internal code duplication (filters valves have a lot in common) Also, Tomcat has never provided standard request and response wrapper classes for Valves to wrap those objects :( https://issues.apache.org/bugzilla/show_bug.cgi?id=45014 Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Even without valves, there are lots of other ways to customize the container. You can also specify Filters at the global host level (may also add engine to that list). Will there be a way to grab information from the raw request as seen by a Valve today? It's nice to be able to get and set values above (or below, depending on your POV) the servlet API. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkrfJJUACgkQ9CaO5/Lv0PA9HACfUfqecyV/Fcx2T18IhypRqVpl ZVUAlAmzCezD2+sTBLvm0atb/VwXadI= =n64M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Valves being converted to Filters?
Hi, I was looking at Bug 47330 (https://issues.apache.org/bugzilla/show_bug.cgi?id=47330) which is a filter / valve implementation of a Httpd's mod_remoteip module. What concerned me is a comment by the submitter at the very bottom of the report: ... As Tomcat valves are currently being converted into Servlet Filter (1), here is a Servlet Filter implementation... Is this true? Is Tomcat moving away from valves and towards filters in the next version(s)? Is there a specific reason for this? Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Am I misunderstanding the comment, or is the submitter mis-informed? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valves being converted to Filters?
Hello Henri, I was referring to public information such as : - Google Summer Of Code 2009, project Convert current Tomcat valves to Servlet Filters : http://wiki.apache.org/tomcat/SummerOfCode2009 and the various associated emails on Tomcat dev mailing list. - Mark Thomas post on Tomcat users mailing list : ...47330 is on the todo list but my current plan is to implement it as a Filter rather than a valve. (1) However, my understanding is not that pluggable 'interceptors' will be removed from the container, just that the Valve API will be replaced with a Filter API. I feel interfaces (HttpServletRequest HttpServletResponse) will be much more easy to manipulate than the current implementations (Request, Response). Hopr this clarifies my message, Cyrille -- Cyrille Le Clerc clecl...@xebia.fr cyri...@cyrilleleclerc.com http://blog.xebia.fr (1) http://www.nabble.com/Re%3A-Cannot-set-remote-address-in-valve-%28Tomcat-5.5%29-p25632043.html On Tue, Oct 20, 2009 at 10:38 PM, Eric B. ebe...@hotmail.com wrote: Hi, I was looking at Bug 47330 (https://issues.apache.org/bugzilla/show_bug.cgi?id=47330) which is a filter / valve implementation of a Httpd's mod_remoteip module. What concerned me is a comment by the submitter at the very bottom of the report: ... As Tomcat valves are currently being converted into Servlet Filter (1), here is a Servlet Filter implementation... Is this true? Is Tomcat moving away from valves and towards filters in the next version(s)? Is there a specific reason for this? Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Am I misunderstanding the comment, or is the submitter mis-informed? Thanks, Eric - 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
Re: Valves being converted to Filters?
From: Eric B. ebe...@hotmail.com To: users@tomcat.apache.org Sent: 20/10/09, 15:38:59 Subject: Valves being converted to Filters? Is this true? Is Tomcat moving away from valves and towards filters in the next version(s)? Sort off. Ideally everywhere but I suspect some valves will remain. Is there a specific reason for this? Portability, reduce internal code duplication (filters valves have a lot in common) Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Even without valves, there are lots of other ways to customize the container. You can also specify Filters at the global host level (may also add engine to that list). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Valves being converted to Filters?
Mark Thomas ma...@apache.org wrote in message news:200910202047470...@265006334... Although I love filters, I find that valves have a very specific need within the container as well; it allows you to configure the container independently of the application. If everything is moving to filters, that would require me to modify the app everytime I want the container to behave slightly differently. Even without valves, there are lots of other ways to customize the container. You can also specify Filters at the global host level (may also add engine to that list). Really? Does that exist already? So far, the only place I know about where I can configure filters are in the web.xml file(s) - both in the application's web.xml and in the server's global web.xml. Is there another place / manner in which to configure a filter on a per-host basis? Or is this something that is only going to be available in a future release? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Valves being converted to Filters?
So is there still going to be an API to plug into the tomcat internals and do things that the servlet API does not support? E -Original Message- From: Cyrille Le Clerc [mailto:clecl...@xebia.fr] Sent: Tuesday, October 20, 2009 4:06 PM To: Tomcat Users List Subject: Re: Valves being converted to Filters? Hello Henri, I was referring to public information such as : - Google Summer Of Code 2009, project Convert current Tomcat valves to Servlet Filters : http://wiki.apache.org/tomcat/SummerOfCode2009 and the various associated emails on Tomcat dev mailing list. - Mark Thomas post on Tomcat users mailing list : ...47330 is on the todo list but my current plan is to implement it as a Filter rather than a valve. (1) However, my understanding is not that pluggable 'interceptors' will be removed from the container, just that the Valve API will be replaced with a Filter API. I feel interfaces (HttpServletRequest HttpServletResponse) will be much more easy to manipulate than the current implementations (Request, Response). Hopr this clarifies my message, Cyrille - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
