How to display data from a servlet to a jsp page

I have mada a servlet which takes a query from one jsp page and process the data.But now i want to display the data to the jsp page.

When i write the code which i use to display the data to a jsp page it does not work

res.sendRedirect("localhost:8080/library/jsppages/Hello1.jsp");

thanking you

in advance

Read up on the requestDispatcher.forward method and the HttpServletRequest object.

If you want to see these working in an example app, got to http://simple.souther.us and download SimpleMVC.

"Yash"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the

JavaRanch Naming Policy.

You can change it

here.

Thanks! and welcome to the JavaRanch!

Mark

Hi,

You can put that data which you want to display into session scope. Then you make use of that session variable to display in JSP.

Bye

using request scope is far preferred for data that doesn't need to be persisted between requests.
Saves a lot of potentially unwanted sideeffects if you (accidentally or on purpose) use the same attribute name in different servlets and JSPs (like I do, as I have the core of a whole range of servlets in an abstract baseclass which sets quite a few things for all the derived classes (in fact it sets just about everything).

"yashmca"

That still does not match the naming policy.

The Naming Policy requires a real first and last name seperated by a space.

Mark

Your redirect approach is used in what I call the "Post, Redirect, Get" pattern.

This has some neat advantages over the servlet forwarding to the JSP

The user can refresh the display page without that annoying message about reposting a request

If the POST does updates, posting again may be dead wrong

The user can bookmark the display page

Nice separation of concerns - update code and display code. You get that already with servlet & jsp but this is stronger yet.

Originally posted by Stan James:
Your redirect approach is used in what I call the "Post, Redirect, Get" pattern.

I use this almost constantly. I found that building sites around this behaviour takes a little more organisation, but many HTTP and browser problems disappear, and the page responsibilities are cleaner.

Your redirect approach is used in what I call the "Post, Redirect, Get" pattern.

I also use a similar pattern which differs just slightly:

Browser POSTs an input form to the server
The server updates resources accordingly
The server redirects to a controller (display support) servlet
The browser GETs the controller servlet
The server reads the resources needed to display the supported page
The servlet forwards to the page
The server returns the display page

All server 'hits' trigger a controller servlet -- each page has such a controller servlet to marshal any data that the page needs in order to render. The JSPs themselves are scriptless and use only the JSTL, EL and custom tags.

The point of these patterns is, of course, to not leave the POST that performed an operation 'dangling" on the browser. And David's point is a good one: this makes for a nice "orderly" application.
[ January 14, 2005: Message edited by: Bear Bibeault ]

The drawback to this pattern is that you loose the first request.

How do you generally persist your data between requests?
Do you always store in session or do you have to make an extra trip to the database?

Also, I've had the misfortune of having to deal with firewalls that don't allow redirects, but not recently.
[ January 15, 2005: Message edited by: Ben Souther ]

Bear's extension with a controller is good. I was thinking of how my Wiki works and it's not quite like servlet / JSP.

After doing the update, the redirect has to contain enough key information to retrieve the right data. The POST for the update might contain a ton of data, but the redirect & get might only need a primary key as a URL parameter.

Oh, reading again that wasn't exactly your question. Yes, database storage has been my experience ... I've mostly done this when the POST will update something persistent.

BTW: Is "post, redirect, get" a common name for this? Is it like a Sun pattern or anything? I saw it in a magazine I think and have used it heavily ever since.
[ January 15, 2005: Message edited by: Stan James ]

Good question Ben.

I do not apply this pattern to each and every operation. It is mostly applied to operations where, in order to display the results, a new trip to the server is required regardless of whether a forward or rediect would be used, or cases where 'replaying' the operation via a refresh would have detrimental consequences.There seems to be no physical force in the universe stronger than the urge for a user to click on that blasted refresh button.

An example that pops to my head from something I was working on the other day: a page shows a summary list of records from the db. The list is paged and allows the user to select records for deletion. After clicking the Delete button and executing the delete on the back end, a new database fetch for the page is required to get the list of records for the current 'page'. So the fact that a redirect occured to 'clear' the delete post off the page introduces only minimal operational overhead.

There seems to be no physical force in the universe stronger than the urge for a user to click on that blasted refresh button.

That's where you are wrong. The urge to click the back button is much stronger..

I use this pattern myself when logging people in and out to prevent someone else from backing up and refreshing to log themselves into the last person's session.

Thanks.

That's where you are wrong. The urge to click the back button is much stronger..

You're right! I stand corrected!