ForwardView?

[jeje]

Hi,

I do have some code using the RedirectView with the contextRelative flag set to "true". But this does not work as I could expect when testing on Tomcat 5 and WAS 4.

The only reliable way to do an "internal" redirect is to use the RequestDispatcher.forward() method. Why do the RedirectView class not use this strategy if contextRelative == true?

Regards,
Jérôme.

[feester]

To do RequestDispatcher.forward() you want to use:
org.springframework.web.servlet.view.InternalResou rceView

To Spring Team FWIW:
There is a RedirectView, so why isn't there a ForwardView and an IncludeView instead of combining both in InternalResourceView?

There are people that actually know the Servlet specification. Why not make it easy for them to find what they need by using meaningful names?

And I don't see any benefit in combining both capabilities in one class.

[jeje]

This is effectively quite confusing to have a RedirectView but then an InternalResourceView for forwards and includes :-)

Thanks for the info.

[Colin Sampaleanu]

Hi,

I do have some code using the RedirectView with the contextRelative flag set to "true". But this does not work as I could expect when testing on Tomcat 5 and WAS 4.

The only reliable way to do an "internal" redirect is to use the RequestDispatcher.forward() method. Why do the RedirectView class not use this strategy if contextRelative == true?

Regards,
Jérôme.

How does this not work as you expect?

RedirectView always does a redirect via HttpServletResponse.sendRedirect, or via sending an HTTP 303 code if the http 1.0 flag is off, never via a forward. When the JavaDoc talks about doing an internal or external redirect, it means internal or external to the site, not that forward is ever used. You actually almost never would want to use forward, since that would reused any form POSTing params for the forwarded request, not generally desireable.

All the contextRelative flag does, which should generally be true for almost all uses, is telling Spring that the path is relative to the context. In this case, Spring will itself prepend the context path before sending the request to the sendRedirect(). Note also that how the Servlet container treated urls changed slightly from 2.2 to 2.3+. In 2.2, urls had to be absolute, or relative to the current request, whereas in 2.3, urls which start with / are considered relative to the servlet container root. But in any of these environments, what you probably want to do is set the contextRealtive flag to true, so that your url will be considered relative to the context root, not the servlet root. Your url in this case should start with /.

I'll update the JavaDocs to be a bit more clear on what the internal means for this class, and when the contextRelative flag is critical and when it's not.

[jeje]

RedirectView always does a redirect via HttpServletResponse.sendRedirect, or via sending an HTTP 303 code if the http 1.0 flag is off, never via a forward. When the JavaDoc talks about doing an internal or external redirect, it means internal or external to the site, not that forward is ever used. You actually almost never would want to use forward, since that would reused any form POSTing params for the forwarded request, not generally desireable.

I do need a redirection but not by the response.sendRedirect() method. If the redirect is internal, you should use instead the RequestDispatcher, otherwise, depending on your app server and the way you deploy your application, the redirect might not be the one expected! So the code should be updated so that when the contextRelative flag is set to true, you use a RequestDispatcher instead a sendRedirect() method.

All the contextRelative flag does, which should generally be true for almost all uses, is telling Spring that the path is relative to the context. In this case, Spring will itself prepend the context path before sending the request to the sendRedirect(). Note also that how the Servlet container treated urls changed slightly from 2.2 to 2.3+. In 2.2, urls had to be absolute, or relative to the current request, whereas in 2.3, urls which start with / are considered relative to the servlet container root. But in any of these environments, what you probably want to do is set the contextRealtive flag to true, so that your url will be considered relative to the context root, not the servlet root. Your url in this case should start with /.

Which is already the case in my app. But I do development on Tomcat 5 and production on WAS 4. So, I'm first restricted to servlet 2.2 and can assure you that when you've using the RedirectView with contextRelative set and path starting with / that Tomcat 5 and WAS 4 (with an Apache front-end [well the WAS one]), the redirect simply fail while the redirect through the RequestDispatcher work. The RequestDispatcher was somehow made for that no?

I'll update the JavaDocs to be a bit more clear on what the internal means for this class, and when the contextRelative flag is critical and when it's not.

That will probably make it easier to understand anyway :-)

[Colin Sampaleanu]

RedirectView always does a redirect via HttpServletResponse.sendRedirect, or via sending an HTTP 303 code if the http 1.0 flag is off, never via a forward. When the JavaDoc talks about doing an internal or external redirect, it means internal or external to the site, not that forward is ever used. You actually almost never would want to use forward, since that would reused any form POSTing params for the forwarded request, not generally desireable.

I do need a redirection but not by the response.sendRedirect() method. If the redirect is internal, you should use instead the RequestDispatcher, otherwise, depending on your app server and the way you deploy your application, the redirect might not be the one expected! So the code should be updated so that when the contextRelative flag is set to true, you use a RequestDispatcher instead a sendRedirect() method.

No we shouldn't, because a redirect is a redirect, and a forward (what you are talking about) is a forward. You can't just do a forward to another controller in many cases, because as I mentioned in the case of a POST you are going to feed the second controller the same values as you gave the first one, not what you want. Additionally, there are other issues since your reuqest and response are the same ones, different interceptors may be involved, and so on. A forward is not a clean way to to a redirect to another controller, which is what the redirectview is for. If all you need is to go to another view, then just use a normal view...

All the contextRelative flag does, which should generally be true for almost all uses, is telling Spring that the path is relative to the context. In this case, Spring will itself prepend the context path before sending the request to the sendRedirect(). Note also that how the Servlet container treated urls changed slightly from 2.2 to 2.3+. In 2.2, urls had to be absolute, or relative to the current request, whereas in 2.3, urls which start with / are considered relative to the servlet container root. But in any of these environments, what you probably want to do is set the contextRealtive flag to true, so that your url will be considered relative to the context root, not the servlet root. Your url in this case should start with /.

Which is already the case in my app. But I do development on Tomcat 5 and production on WAS 4. So, I'm first restricted to servlet 2.2 and can assure you that when you've using the RedirectView with contextRelative set and path starting with / that Tomcat 5 and WAS 4 (with an Apache front-end [well the WAS one]), the redirect simply fail while the redirect through the RequestDispatcher work. The RequestDispatcher was somehow made for that no?

Tomcat 5 works absolutely fine with RedirectView, with or without the ContextRelative flag set true. If you are having issues I would guess that they are related to how you have set up Apache in front. Ultimately, what you have to realize is that for a redirect, the servlet engine needs to issue an absolute url back to the client. So it needs to have the external path come in properly with the request, which is what happens when Apache is connected to the servlet engine via something like a connector, or in the case where Apache is doing http-based proxy forwarding, Apache needs to do rewriting on the returned content so internal urls (like the redirect) get mapped propertly to external urls. Even with a connector you may have to do this rewriting, if you are doing some sorts of rewriting going in.

As for the RequestDispatcher.forward(), the reason it's working for you, is because it's not a redirect, as I mentioned, all it's doing is forwarding internally to the servlet engine, but you just can't do the same things with it...