What is wanted:
1) Start the JSP page with temporary data (works).
2) At a later time, send a new xml object to the doPost method (works - I get the data in the doPost method).
3) Display the new data in the JSP (does not work).
*** I have not found a way (probably really obvious) to get the new object to the JSP backing bean from the servlet.
1) When the data comes in it hits the doPost method correctly.
2) The doPost method does a
(The request is correctly loaded with the data).
3) The initial method in the JSP backing bean is hit correctly.
4) The backing bean does not extend fron HttpServlet, so not able to get the servlet request parameter directly - not sure how to retrieve the data.
Temporary workaround scenario:
1) Fake data input by reading from a xml disk file.
2) Open a Firefox browser window and view the initial display based on the xml data.
2) Hand edit the xml file.
3) Send the new file to the doPost method from the external program, which writes the new data to the old xml disk file correctly.
*** The problem is displaying the new data. If the browser window (Firefox) is kept open, the old data is always displayed. Various attempts such as Cntl-Refresh, Cntl-F5 etc. to do display the new data. If I completely close Firefox and reopen, type in the JSP URL, the new data is correctly displayed. Maybe this is a Firefox problem, but it also does not work in the Eclipse web window.
*** If problem #1 is fixed, I would like to programatically refresh the data when the doPost is hit. Is there a way to force that?
You have a fundamental misunderstanding of how not only J2EE works, but also how the web itself works.
HTTP is not a client/server architecture in the sense that a remote user connects to an application, communicates with that application and eventually disconnects from that application.
Instead, HTTP works on a series of short request/response transmissions paired on a one-to-one basis. That is, every request is replied to with a response. Responses are ONLY sent in answer to a request. There is no permanent connection. A separate connection is established and broken for each request/response cycle. The application does not process except when a request has come in and a response is being generated. Because of this, you cannot display a JSP in one browser window, send a servlet request from somewhere else, and expect to push out an unsolicited response that updates the JSP. Responses are always returned to their requester.
OK, I realize that that seems ridiculous, considering that in most webapps, you DO log in, do things, and log out. However it's all smoke and mirrors. The browser and server conspire to give the illusion of a continuous session using various tricks such as cookies and J2EE HTTPSession objects. Nonetheless, the basic limitation that unsolicited responses are not allowed remains.
An IDE is no substitute for an Intelligent Developer.
Joined: Aug 05, 2010
Thank you for your response. I guess my second question was badly written.
What I am wondering about is this (Problem #2):
If the webapp is started and the initial JSF/JSP request comes in from a browser (IE or Firefox) the default data (from a file) is displayed as it should be.
I use the test driver to send new data to the doPost method. The data is input and passed via forward(request, response) call is made to the JSF/JSP. The JSF/JSP backing bean methods are correctly called.
I realize the IE/Firefox is not updated automatically. However, there seems to be no way to refresh either browser unless it the browser is shut down and restarted. If fact, I can have, say, the Firefox browser displaying the original data (IE is shut down), send new test driver data. If I then bring up an IE browser, the correct new data displays - or vice versa.
It seems there should be a way to refresh the browser data without shutting down the browser (obviously there is, I just don't know what it is). Things like the Refresh button on the browser, cntl Refresh, cntl+F5, etc do not work - the old data stays.
The main problem is having the JSF/JSP pick up data from the doPost forward (Problem #1).
I cannot: ClassA myAttClass = (ClassA) request.getAttribute("MyAttName"); in the backing bean as the backing bean does not know about "request" even though a method in it triggers when I send the forward(request, response). Note, there is proprietary JSTL code in the JSF/JSP and I do not have that source code.
*** I am wondering how to read the "request" that was passed in the forward call when the the JSF/JSP backing bean triggers. ****
I recommend you not use the term "JSP" to refer to JSF view requests. Even if you're using view prototypes with the ".jsp" extension instead of ".xhtml", it's confusing, since it's perfectly legal to mix "real" JSPs with JSF. And when you're already talking Servlets, it makes it just that much more ambiguous.
I try and avoid forwarding as much as possible. It complicates things and adds overhead.
Anyway, aside from the editorializing, if you have truly updated the session backing data, subsequent page requests should be displaying that data, whether the request routes through a servlet, a JSP or through the JSF servlet. That's true on raw URL requests, postbacks, browser refresh requests and META page update requests. The only reason that that shouldn't happen is if the data is stored somewhere that isn't shared. For example in request scope for a single browser, or in cases where you're using session scope with 2 different browsers such as IR and Firefox (since each brand of browser gets its own session, even though that session is the same for all tabs and windows for that browser).