Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2006

Tip: Looking for answers? Try searching our database.

Servlets, send redirect and request scope

Thread view: 
Berlin  Brown - 30 Aug 2006 23:40 GMT
In a typical (MVC1) application.  You have a HTML-FORM posting to
servlet-A and getting request parameters/values from the request
object.

HTML-FORM ==> Servlet-A

If I have to put a redirect in between the form and A.  The request
values are lost.   Is there a generic way to restore those request
values.  I could put all the keys/values in a session object and then
recollect the values in the servlet.  But, I wish there was a generic
way that possibly avoided using the session object.

HTML-FORM ==> response?.sendRedirect ==> Servlet-A

Something like response.putRequestValue...
Arne Vajhøj - 31 Aug 2006 02:28 GMT
Berlin Brown wrote:
> In a typical (MVC1) application.  You have a HTML-FORM posting to
> servlet-A and getting request parameters/values from the request
[quoted text clipped - 11 lines]
>
> Something like response.putRequestValue...

Why not use forward instead of redirect ?

(that will keep request info)

Arne
Berlin  Brown - 31 Aug 2006 03:23 GMT
Security reasons.  It is needed to do the redirect.

> Berlin Brown wrote:
> > In a typical (MVC1) application.  You have a HTML-FORM posting to
[quoted text clipped - 18 lines]
>
> Arne
Arne Vajhøj - 31 Aug 2006 03:30 GMT
Berlin Brown wrote:
> Security reasons.  It is needed to do the redirect.

Then sessions or a special cookie.

Arne
Berlin  Brown - 31 Aug 2006 04:48 GMT
Yea, but it isnt as clean and not generic.  For example, I would have
find every instance of request 'getParameters' that existed at the end
servlet and replace with the session getting code.

I wish there was a way to fill in values in the request object, that
way I wouldnt have to change any code at all.

> Berlin Brown wrote:
> > Security reasons.  It is needed to do the redirect.
>
> Then sessions or a special cookie.
>
> Arne
Chris Smith - 31 Aug 2006 07:52 GMT
> Yea, but it isnt as clean and not generic.  For example, I would have
> find every instance of request 'getParameters' that existed at the end
> servlet and replace with the session getting code.
>
> I wish there was a way to fill in values in the request object, that
> way I wouldnt have to change any code at all.

And with a modern servlet spec, there is!  You'll still have to get the
new information to the new request somehow.  Once it's there, though,
you can set up a servlet filter that builds a wrapped ServletRequest
object and adds parameters and/or request attributes.  Google on servlet
filters for details.

Signature

Chris Smith

Berlin  Brown - 31 Aug 2006 14:06 GMT
How would I do that.  I know about filters.  But what about in this
context.

Would I use the redirect to hit a 'filter'.

> > Yea, but it isnt as clean and not generic.  For example, I would have
> > find every instance of request 'getParameters' that existed at the end
[quoted text clipped - 8 lines]
> object and adds parameters and/or request attributes.  Google on servlet
> filters for details.
Chris Smith - 31 Aug 2006 15:47 GMT
> How would I do that.  I know about filters.  But what about in this
> context.
>
> Would I use the redirect to hit a 'filter'.

Yes.  For example, you might use something like this:

1. Set a session attribute before you redirect containing the desired
request attributes and parameters.

2. Install a filter that intercepts all requests.

 - If the session attribute doesn't exist, then just pass the request
   along the chain without doing anything.

 - If the session attribute does exist, then build a wrapped request
   that returns the desired attributes and parameters, and pass that
   along the chain.

Signature

Chris Smith

Berlin  Brown - 31 Aug 2006 16:42 GMT
What you are saying makes sense, except for the last part. Let me add a
little bit more pseudo code (note I have some of my code in there):

public class TestReconnectServlet extends BaseServlet {
 doPost() {

    String theKey = request.getParameterKey();
    String theValue = request.getParameter(theKey);
    Object arr [] = new Object[2];
    arr[0] = theKey;
    arr[1] = theValue;
    session.setValue("mysession.before.redirect", arr);
    response.sendRedirect(GoToFilter?);

 }
}
public class TheFilter implements Filter {
 public void doFilter(ServletRequest reqBasic, ServletResponse
respBasic, FilterChain chain) {

 HttpServletRequest req = (HttpServletRequest) reqBasic;
            HttpServletResponse res = (HttpServletResponse) respBasic;

 /// Here ????????? build up the request object?
 String key, value = session.getValue(arr);
 request .setValue(key, value);

...

 chain.doFilter(req, res);

}
}

Hmm, this might actually work?

response.sendRedirect(GoToFilter?);

When I do the redirect, it is to the GoToFilter?

> > How would I do that.  I know about filters.  But what about in this
> > context.
[quoted text clipped - 14 lines]
>     that returns the desired attributes and parameters, and pass that
>     along the chain.
Chris Smith - 31 Aug 2006 17:01 GMT
>   /// Here ????????? build up the request object?
>   String key, value = session.getValue(arr);
>   request .setValue(key, value);

Check the API docs for javax.servlet.http.HttpServletRequestWrapper.  
You'd build a subclass of that, and pass it to FilterChain.doFilter in
place of the original ServletRequest.

Signature

Chris Smith



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.