Hi, I've got Jens' code ( see https://issues.apache.org/bugzilla/show_bug.cgi?id=14766 ) completed and working. My implementation uses Java regex for matching the URLs to redirect and regex capturing groups for substitutions into redirection URLs. This sort of functionality looks quite demanded, and googling shows several in-house implementations of Redirect Valves existing out there... Is my implementation of any interest to the project? If yes, what are my next steps?
Create a patch and attach it to the bug, if someone takes an interest in it, it might get committed.
Created attachment 27246 [details] A proposed implementation for a Redirect valve The main code of the proposed valve implementation.
Created attachment 27247 [details] The .properties file in English
Created attachment 27248 [details] The .properties file in Russian
Comment on attachment 27247 [details] The .properties file in English To be merged with the corresponding properties file in the existing package.
A few questions: 1. Why a Valve and not a Filter? 2. Why not use urlrewrite like everyone else?
(In reply to comment #6) Well, there is nothing wrong about UrlRewriteFilter except it is a filter :) It looks perfect and mature, but it is good for webapp-level tasks rather than container-level tasks. A filter being a part of a webapp belongs to the responsibility of a developer, while there may be quite a variety of redirection tasks that belong to the administration domain. So one of the motivations for a valve is separation of responsibilities of a developer and an administrator. Another motivation is that there may be quite a lot of various redirection tasks common for different webapps at a server, which might be better taken care of in a centralized manner with a valve... Regards, Sergey
(In reply to comment #7) > Well, there is nothing wrong about UrlRewriteFilter except it is a filter :) > It looks perfect and mature, but it is good for webapp-level tasks rather than > container-level tasks. Tomcat 7 can use Filters at the container level. Configure them just as you configure Valves, except that you use <Filter> instead of <Valve>.
(In reply to comment #8) > Tomcat 7 can use Filters at the container level. Configure them just as you > configure Valves, except that you use <Filter> instead of <Valve>. Where did that come from? It is news to me. Filters can be defined in the global web.xml, the host level web.xml or an app's web.xml (although you do get one instance per application). I am struggling to see the benefit of this Valve compared to the urlrewrite, particularly given the features that urlrewrite has compared to this patch.
(In reply to comment #9) > (In reply to comment #8) > > Tomcat 7 can use Filters at the container level. Configure them just as you > > configure Valves, except that you use <Filter> instead of <Valve>. > > Where did that come from? It is news to me. I thought filters could be configured in <Context> elements in META-INF/context.xml, hence the (slight) push to re-write Valves as Filters so they would be more portable. > I am struggling to see the benefit of this Valve compared to the urlrewrite, > particularly given the features that urlrewrite has compared to this patch. I completely agree. I'm sure it would be useful for /some/ people to incorporate all kinds of things from other projects into Tomcat, but it's not really appropriate if they already exist, are well-known, and well-supported.
(In reply to comment #9) > I am struggling to see the benefit of this Valve compared to the urlrewrite, > particularly given the features that urlrewrite has compared to this patch. Well, let's consider a task of mapping/redirecting a Tomcat app to a virtual directory at a front-end server. To start with, it is an administrative task, not a developer's one, so the app's WEB-INF does not look the right place to set it up. The server admin is not likely to be happy tinkering with the war file or the unpacked folder every time the developer issues a new version of the app. The next place to consider for a filter is the the global web.xml or host-level web.xml. This is likely to do the job, but the fact that the appropriate filter is going to be instantiated in multiple useless copies for every app, makes the whole construct strange-looking too. So a valve looks the most straightforward approach to do the job... (In reply to comment #10) > I'm sure it would be useful for /some/ people to incorporate all kinds of > things from other projects into Tomcat, but it's not really appropriate if they > already exist, are well-known, and well-supported. Well, to my mind it's not incorporating existing functionality from other projects into Tomcat, but rather adding something new and missing. This first implementation maybe does not look great, but it may eventually get more flesh, as new requirements get outlined by the practice...
Just one more word regarding reluctance to incorporate existing mature functionality into Tomcat. I would personally be happy to use UrlRewrite for the mentioned tasks if this filter gets the Valve interface implemented one day... Or maybe gets a wrapper to implement the Valve interface... But can we expect this? There may be a potential obstacle on that way that Filter is a standard and container-independent concept, while Valve is specific for Tomcat...
(In reply to comment #12) > Just one more word regarding reluctance to incorporate existing mature > functionality into Tomcat. > > I would personally be happy to use UrlRewrite for the mentioned tasks if this > filter gets the Valve interface implemented one day... Or maybe gets a wrapper > to implement the Valve interface... I'd honestly be happy if my earlier assertion that <Filter> could be used in place of a <Valve> were true. I'll look into what that would take to accomplish. Maybe a Valve implementation wrapper around the Filter interface. That shouldn't actually be that hard, honestly. I'll look into it. Let's move this discussion onto the dev list and out of BZ.