You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jake Vang <va...@googlemail.com> on 2009/02/12 06:13:09 UTC
Filter versus Valve
I've been looking for a way to modify my request header. I found that
implementing javax.servlet.Filter is the way to go. However, I noticed that
once after I got my Filter implementation working, my Valve is no longer
reached (I created my own Valve subclassing
org.apache.catalina.valves.ValveBase). I've determined this because I've
placed breakpoints in the Filter.doFilter(...) method and Valve.invoke(...)
methods, and only the breakpoint in the Filter class implementation is
caught.
My context XML for my web application is:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/my-valve"
docBase="C:\my-valve\dist"
reloadable="true">
<Valve className="vang.jake.tomcat.valve.ModifyHeaderValve" />
</Context>
My web.xml for my web application is:
<filter>
<filter-name>simpleFilter</filter-name>
<filter-class>vang.jake.servlet.filter.SimpleFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>simpleFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Could someone clarify if the use of one (filter) precludes the use of the
other (valve)? If so, why? If not, why is my valve never reached?
Thanks.
Re: Filter versus Valve
Posted by Jake Vang <va...@googlemail.com>.
The code for the Filter implementation:
public class SimpleFilter implements Filter {
public void destroy() {
}
public void doFilter(ServletRequest servletRequest, ServletResponse
servletResponse,
FilterChain filterChain) throws IOException, ServletException {
if(servletRequest instanceof HttpServletRequest) {
HttpServletRequest httpServletRequest =
(HttpServletRequest)servletRequest;
FakeHeadersRequest request = new
FakeHeadersRequest(httpServletRequest);
filterChain.doFilter(request, servletResponse);
} else {
filterChain.doFilter(servletRequest, servletResponse);
}
return;
}
public void init(FilterConfig filterConfig) throws ServletException {
}
}
The code for the Valve subclass:
public class ModifyHeaderValve extends ValveBase {
public void invoke(Request request, Response response, ValveContext
valveContext)
throws IOException, ServletException {
if(
!(request instanceof HttpRequest) ||
!(response instanceof HttpResponse)
) {
valveContext.invokeNext(request, response);
return;
}
if(
!(request.getRequest() instanceof HttpServletRequest) ||
!(response.getResponse() instanceof HttpServletResponse)
) {
valveContext.invokeNext(request, response);
return;
}
HttpServletRequest httpServletRequest = (HttpServletRequest)request;
FakeHeadersRequest fakeHeadersRequest = new
FakeHeadersRequest(httpServletRequest);
String value = fakeHeadersRequest.getHeader("username");
valveContext.invokeNext(request, response);
return;
}
}
The code for the FakeHeadersRequest:
public class FakeHeadersRequest extends HttpServletRequestWrapper {
public FakeHeadersRequest(HttpServletRequest request) {
super(request);
}
public String getHeader(String name) {
HttpServletRequest request = (HttpServletRequest)getRequest();
if("username".equals(name)) {
Cookie[] cookies = request.getCookies();
for(int i=0; i < cookies.length; i++) {
if("username".equals(cookies[i].getName())) {
String val = cookies[i].getValue();
return val;
}
}
}
return request.getHeader(name);
}
public Enumeration getHeaderNames() {
List list = new ArrayList();
HttpServletRequest request = (HttpServletRequest)getRequest();
Enumeration e = request.getHeaderNames();
while(e.hasMoreElements()) {
String n = (String)e.nextElement();
list.add(n);
}
list.add("username");
Enumeration en = Collections.enumeration(list);
return en;
}
}
On Thu, Feb 12, 2009 at 3:05 AM, Kees de Kooter <kd...@gmail.com> wrote:
> Could you post the code of your valve and your filter?
>
> Please also not that a Valve is a tomcat specific thing i.e. not
> portable to other app servers. A Filter is part of the servlet spec
> and portable.
>
>
> On Thu, Feb 12, 2009 at 06:13, Jake Vang <va...@googlemail.com> wrote:
> > I've been looking for a way to modify my request header. I found that
> > implementing javax.servlet.Filter is the way to go. However, I noticed
> that
> > once after I got my Filter implementation working, my Valve is no longer
> > reached (I created my own Valve subclassing
> > org.apache.catalina.valves.ValveBase). I've determined this because I've
> > placed breakpoints in the Filter.doFilter(...) method and
> Valve.invoke(...)
> > methods, and only the breakpoint in the Filter class implementation is
> > caught.
> >
> > My context XML for my web application is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <Context path="/my-valve"
> > docBase="C:\my-valve\dist"
> > reloadable="true">
> > <Valve className="vang.jake.tomcat.valve.ModifyHeaderValve" />
> > </Context>
> >
> > My web.xml for my web application is:
> >
> > <filter>
> > <filter-name>simpleFilter</filter-name>
> > <filter-class>vang.jake.servlet.filter.SimpleFilter</filter-class>
> > </filter>
> > <filter-mapping>
> > <filter-name>simpleFilter</filter-name>
> > <url-pattern>/*</url-pattern>
> > </filter-mapping>
> >
> > Could someone clarify if the use of one (filter) precludes the use of the
> > other (valve)? If so, why? If not, why is my valve never reached?
> >
> > Thanks.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Filter versus Valve
Posted by Kees de Kooter <kd...@gmail.com>.
Could you post the code of your valve and your filter?
Please also not that a Valve is a tomcat specific thing i.e. not
portable to other app servers. A Filter is part of the servlet spec
and portable.
On Thu, Feb 12, 2009 at 06:13, Jake Vang <va...@googlemail.com> wrote:
> I've been looking for a way to modify my request header. I found that
> implementing javax.servlet.Filter is the way to go. However, I noticed that
> once after I got my Filter implementation working, my Valve is no longer
> reached (I created my own Valve subclassing
> org.apache.catalina.valves.ValveBase). I've determined this because I've
> placed breakpoints in the Filter.doFilter(...) method and Valve.invoke(...)
> methods, and only the breakpoint in the Filter class implementation is
> caught.
>
> My context XML for my web application is:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Context path="/my-valve"
> docBase="C:\my-valve\dist"
> reloadable="true">
> <Valve className="vang.jake.tomcat.valve.ModifyHeaderValve" />
> </Context>
>
> My web.xml for my web application is:
>
> <filter>
> <filter-name>simpleFilter</filter-name>
> <filter-class>vang.jake.servlet.filter.SimpleFilter</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>simpleFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> Could someone clarify if the use of one (filter) precludes the use of the
> other (valve)? If so, why? If not, why is my valve never reached?
>
> Thanks.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org