Want to doFilter *AND* forward

[Elie Hirschman]

I would like to code a page where the form will autosave when the user navigates away (to another page within the site) without saving. I am trying to do this with a servlet filter, but I am running into a problem.
I would like to do something like this:

 
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException
    {
        if (req != null)
        {
            HttpServletRequest requestURL = (HttpServletRequest) req;
            HttpSession mySession = requestURL.getSession();
            //get the url to submit the save params
            String saveUrl = (String) requestURL.getParameter("saveUrl");
            System.out.println(saveUrl);
            if (saveUrl != null)
            {
                 RequestDispatcher x = requestURL.getRequestDispatcher(saveUrl);
                //run the save
                x.forward(requestURL, res);
            }
 
            }
        //go to the destination url
        chain.doFilter(req, res);
 
    }

...but it seems from all the searches I have done that one can only do either the doFilter or the forward. I have set up a test version, and it seems to run the "saveUrl" and populate the url toolbar with the "destinationURL" + parameters, but not actually load the page I wanted to redirect to.
Any thoughts? Is it ever possible to do both a forward and a chain.doFilter? If not, what are my options to do what I am trying to do?
[ August 07, 2006: Message edited by: Elie Hirschman ]

[Ben Souther]

How are you getting the form values to the server?

[ramprasad madathil]

Also though you can legally forward from a filter, I would suggest that some jobs be best left to a controller servlet. A filter's function should be restricted to a generic task (like say checking for the existence of a session or compressing a response).

When you forward the request from a filter, the forwarded resource has the responsibility of writing the output. A call to doFilter() after the request has been forwarded does invoke the target resource of the original url(atleast tomcat doesnt throw an exception), but it cannot write anything to the output stream.

There are other problems with the task you are trying to accomplish. Have you thought about the case where the user wouldnt have filled out all required form parameters and decides to navigate away from the current page. You cannot save the form because all entries havent been filled out and you cannot prompt the user to fill it up because the user never clicked on the save/submit buttons.

This may not have helped solve your problems, but hope you would atleast have a grasp of what you are up against

ram.

Note:

Filters, by default, apply only to the request.
To invoke filters on a forward, you should add the dispatcher element in filter mappings.

<filter-mapping>
   <filter-name>Value</filter-name>
<url-pattern>Value</url-pattern>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>

While that answers how filters can be applied at all points in a request cycle, I would suggest caution with the way you use them.

For example, if you apply a filter to the request and based on some request params, forward to another resource **and use the same filter** on the forwarded resource, you would end up with an infinite loop.

[ramprasad madathil]

but hope you would atleast have a grasp of what you are up against

Add Ben's question to that

How are you getting the form values to the server?

Just to clarify, if the user clicks on some other link rather than saving the form, the form name/value pairs arent transmitted with the new url request automatically (unless ofcourse you have javascripts handling the onClick() event on the link)

ram.

[Elie Hirschman]

Originally posted by ramprasad madathil:


Just to clarify, if the user clicks on some other link rather than saving the form, the form name/value pairs arent transmitted with the new url request automatically (unless ofcourse you have javascripts handling the onClick() event on the link)

ram.

It's funny you mention that, because that's part of the reason we are doing this in the first place. We do have JS hooks in place to catch the click and attempt to submit the form. I've also put code in to see if the form passed validation (using Spring's Validatior class) and if so, forward to the error page instead of what the user clicked.

In short, this is my process: I want to run the save action (SAVE_URL) then check the validation object and either display the response from the save if there is an error (keeping the user on the form submit page), or else throw away the response and allow the flow to continue to where the user clicked (DEST_URL)
Right now, I am using a HttpServletResponseWrapper to catch the response from that first forward into a CharArrayWriter, then checking the request attributes to see if there are BindExceptions. If there are errors, write the CharArrayWriter contents into the response object and display that. Otherwise, call the simple

   filterChain.doFilter(servletRequest, servletResponse);

to go to the URL the user requested.

The problem comes in A. the fact that the browser always seems to use the response returned by the SAVE_URL (i.e., we get the "Thanks for submitting form" page)
B. we are getting an error, apparently when trying to load the DEST_URL:

  java.lang.IllegalStateException: cannot resize buffer, 3287 bytes have been written   

So apparently, the reponses and requests are stepping on each other.

Here is the code as it stands.

  package com.partyrentalltd.props.framework.filters;
 
import org.springframework.validation.Errors;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
 
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.Enumeration;
import java.util.Map;
 
/**
 * This filter is strictly intended to capture requests that have a SAVE_URL in them,
 * call the save URL but ignore the output, then continue to the originally intended URL
 * @since Aug 8, 2006 8:36:23 AM
 *
 * @author Elie Hirschman
 */
public class InternalRedirectFilter implements Filter
{
    private FilterConfig config = null;
    private Log logger = LogFactory.getLog(InternalRedirectFilter.class);
 
    public void init(FilterConfig filterConfig) throws ServletException
    {
        this.config = filterConfig;
    }
 
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException
    {
        if(servletRequest.getParameterValues("TAB") != null)
        {
            if(logger.isInfoEnabled())
            {
                String[] strings = servletRequest.getParameterValues("TAB");
                for (int i = 0; i < strings.length; i++)
                {
                    logger.info("TAB[" + i + "]=" + strings[i] );
 
                }
            }
 
        }
        //first make sure we need to handle it
        if (servletRequest.getParameter("SAVE_URL") == null || servletRequest.getParameter("SAVE_URL").equals("") )
        {
            filterChain.doFilter(servletRequest, servletResponse);
            return;
        }
 
  //If the filter has been run for this request, just allow flow to continue
        if(servletRequest.getAttribute("SkipFilter") != null)
        {
            filterChain.doFilter(servletRequest, servletResponse);
            return;
        }
 
        if (!(servletRequest instanceof HttpServletRequest))
        {
            filterChain.doFilter(servletRequest, servletResponse);
            return;
        }
        HttpServletRequest request = (HttpServletRequest)servletRequest;
        HttpServletResponse response = (HttpServletResponse)servletResponse;
        String url = request.getRequestURL().toString();
        if(logger.isInfoEnabled())
        {
            logger.info("SAVE_URL = " + servletRequest.getParameter("SAVE_URL")) ;
            logger.info("DEST.URL = " + url);
        }
        //wrap the response here
        CharArrayWriter arrayWriter = new CharArrayWriter();
        FilterOutputResponseWrapper wrapper = new FilterOutputResponseWrapper(response, arrayWriter);
        //redirect using a redirector
        request.setAttribute("SkipFilter", "True");
        RequestDispatcher rd = request.getRequestDispatcher(servletRequest.getParameter("SAVE_URL"));
        rd.forward(request, wrapper);
        //response info is saved in the arrayWriter for now
        //Check for validation errors
        Enumeration enumeration = servletRequest.getAttributeNames();
            while (enumeration.hasMoreElements())
            {
                String attribute = enumeration.nextElement().toString();
                if( attribute.indexOf("BindException") >0 )
                {
                    Errors errors = (Errors)servletRequest.getAttribute(attribute);
                    if(errors.hasErrors())
                    {
                        //use the saved response to send the user back to the page
                        if (logger.isInfoEnabled()) logger.info("has errors") ;
                        servletResponse.getWriter().write(arrayWriter.toCharArray());
                        return;
                    }
                }
            }
        //Go to the URL the user requested
        filterChain.doFilter(servletRequest, servletResponse);
    }
 
    public void destroy()
    {
        this.config = null;
    }
 
    class FilterOutputResponseWrapper extends HttpServletResponseWrapper
    {
        PrintWriter printWriter = null;
 
        public FilterOutputResponseWrapper(HttpServletResponse httpServletResponse, Writer writer)
        {
            super(httpServletResponse);
            this.printWriter = new PrintWriter(writer);
        }
 
        public PrintWriter getWriter() throws IOException
        {
            return printWriter;
        }
    }
}  

...but of course, by the time you read this, I will be changing it again, trying to make it work.
Thanks to all for your help.

[ramprasad madathil]

We do have JS hooks in place to catch the click and attempt to submit the form.

Does the JS actually submit the form? Or does it include the information some way in the request that a form needs to be processed? If its the former, you do realize that the destination url is the url the form was submitted to (and not the user click), dont you?

Also, you seem to use a ResponseWrapper while forwarding and the actual response object for the doFilter() to the original url. Why not use the wrapper all the way?

filterChain.doFilter(servletRequest,wrapper);
servletResponse.getWriter().write(arrayWriter.toCharArray());

I still cant figure out why you need a filter for this as opposed to a normal Servlet - this kind of forwarding from a Filter doesnt find mention in the Servlet spec and you may see inconsistent behaviour across servers.

ram.

[Elie Hirschman]

Originally posted by ramprasad madathil:

Does the JS actually submit the form?

filterChain.doFilter(servletRequest,wrapper);
servletResponse.getWriter().write(arrayWriter.toCharArray());

I still cant figure out why you need a filter for this as opposed to a normal Servlet - this kind of forwarding from a Filter doesnt find mention in the Servlet spec and you may see inconsistent behaviour across servers.

ram.

The JS is legacy, so every tab has its own JavaScript function that gets called, which then submits the form (via a generic function). I added code to set a hidden param in the form for the url that the user clicked, so first the action of the form would fire, then the redirect to the clicked url would happen.
But you are 100% correct- we are banging our heads together on this, and the Filter approach no longer makes sense.
We went back to the drawing board this morning and rethought it out - again you were right - Controllers are the way to go.
We are using Spring MVC (at least on the non-legacy stuff) and the form I am trying to autosave is Spring-enabled. We will try extending the Base Spring Controller class and have my custom controller extend that. The JS will remain intact, and the user-clicked URL will be submitted with the form. Within that new controller (after submit) will be code to extract the user click url and return that as the successView to which the redirect should happen. If the parameter is missing, the normal successView (as configured in spring xml config) is returned.
If the form had invalid data, the Validator class never allows it to go thru to the Controller, so no extra coding needed there.
This seems to be a much more staightforward approach, and is inline with Spring specs. I thank you all for your feeback and I will post again when I try this approach out.

[Elie Hirschman]

Success! This approach was much simpler, accompished exactly what we wanted, and it just goes to show you NOT TO OVERTHINK THINGS!
We now have a mechanism in place for any future forms within this web app that we want to equip with autosave functionality.
Thanks again to all.