Reconstruction of request scoped backing beans

Hi,
I have a jsp which contains the following code:
<h:commandButton action="go_someplace" actionListener="#{bean1.update}" value="submit"/>bean1 is this form's backing bean and it is request scoped.
bean1 is passed some parameters from the former page by putting them in the request to that page.
What I notice is that bean1 is constructed once when the form is displayed, but also a second time before the actionListener (update) is invoked.
As a result, the second request to the bean (the HTTP request) does not contain what it originally did in the first request anymore and the data gets reset.
Can anyone please explain this behavior (and offer a solution...).
Thanks,
Zohar

I tried it and it doesn't solve my problem.
I'll try to explain what I have a bit clearer:
I have a form with a person's details: name, age. A person has a unique id.
I have a form with a list of persons. When I select a specific person a new form is shown with that person's details. multiple forms may be opened, so the person's details form is request scoped.
I pass the selected person's id from the list of persons' form using f:param in the form's commandLink. I retrieve this id in the person's details form using httpRequest.getParameter("com.zohar.selectedPersonId");.
I also added a <h:inputHidden value="#{personDetails.personId}"/>I noticed that setPersonId() is invoked after all the form controls are built, so that the getPersonName() (which depends on the person ID) is invoked before setPersonId() is invoked.
Is there a standard way to do this?

Similar Messages

Page scoped backing bean keeps old data, why???

I have two pages, a search/list page and an add page. On the search/list page there is an add buttom that simply navigates to the add page.
The first time I press the add button all fields in the page are blank so I enter data and submits. The data i saved and we are navigated back to the search/list page. The next time I press the add button and are naviagted to the add page, all fields are filled with the same values as the last time I visited the page.
The add page backing bean is (annotated by Seam) to reside in PAGE scope so it should loose its values between invokations of the add page.
I get the exact same instance of the bean every time I nav to the add page. (Until the session is closed of course)
Why this behaviour?
Thanx.

Check if a session scoped bean or other class is keeping a reference to the bean

Feedback requested: in backing bean, use AM svc method or operation binding

Hello all,
I'm posting this here to solicit feedback from both Oracle and from the community at large. The basic question is around what is the best/better practice for calling Application Module service methods from a backing bean. One choice is to call the service method directly on the application module; the other is to put an operation binding in the page definition and to execute that binding. The basic code for the two methods:
((MyAppModule) getBindings().getDataControl.getApplicationModule()).serviceMethod();or
getBindings().getOperationBinding("serviceMethod").execute();My question comes up specifically because of differences in how the default error handling works. For testing, we created a simple AM with a single service method that throws a JboException (a kind of RuntimeException). Then, we created a simple ADF Faces page with an af:messages (to see how error handling works) and four af:commandButtons. The four command buttons are as follows (the code is in the backing bean for each of them):
1). partialSubmit=false, calls application module service method directly
2). partialSubmit=false, executes service method via operationBinding
3). partialSubmit=true, calls application module service method directly
4). partialSubmit=true, executes service method via operationBinding
None of the backing bean methods catch any exceptions. Note that #2 and #4 could be bound directly to the methodBinding in the pagedef, but we did it via code in the backing bean to more accurately mimic some of the code in our application; in any case, the results were the same using either method for #2 and #4.
The results when clicking each button:
1). ugly stack trace in the browser window (yuck!)
2). the af:messages component displays the JboException (nice)
3). No stack trace, no error message (even worse than #1, user thinks "success," even though exception occurred)
4). the af:messages component displays the JboException (nice)
This leads me to think that perhaps calling via the binding container is the preferred method because the default error handling gives acceptable behaviour, whereas using the AM directly gives unacceptable behaviour.
Another "benefit" of calling through the binding container is that the technology in the model layer could be changed without having to change the view layer. I say "benefit" in quotes because I personally believe that one should write applications to take full advantage of the technology they choose, not try to strive for technology/database independence (no flames on this one please - that's not the main point here ;).
Having made the preliminary conclusion that the binding container is the preferred way to go for service methods - that could then ostensibly be extended to view objects as well. Should the view layer use iteratorBindings instead of dealing with view objects directly as well? This is a bit more shaky ground because there are some points in the view/controller layer (namely managed beans not associated with any page) where there is no binding container available. However, in backing beans, for re-executing queries we could make the "best practices" statement to always use iteratorBindings instead of accessing the AM/VO. I just completed a test comparing view object usage vs iterator binding usage (vo.executeQuery() vs myIter.executeQuery()) with similar results to the AM testing - the binding container route gives acceptable error handling, whereas the VO route forces me to implement my own error/exception trapping and message display.
I am aware of one drawback to using the binding container instead of the AM directly - that is that each page that needs the service method must have something in it's pageDef for that method. Originally, we had some code in a superclass of some backing beans that called the AM directly, and we didn't need to touch the pageDefs of approximately 20 JSF pages - when changing to use the operation binding - we had to add it to a lot of page defs.
I'm very interested in feedback from the community at large on my conclusions. If the discussion gets to be too big/complicated for here, we can change venues to perhaps the oracle wiki or another forum. I did do a quick review of SRDemo ADFBC and noted that all of the service method calls are done through operation bindings - I never noticed that before! Most of the discussion we see in the forums shows people calling them directly, which is why I thought it important to post here.
Best regards,
John

What we did in our project was that we create a "Headless" pagedefinition, (that was how it was described in SRDemo documentation or in JDeveloper help, its on the latter part about Security).
You have to create that pagedef manually. and it only has an
<page id="yourPageDef_Id" path="..."> entry in your Databindings and no
<page path=".../yourPageDef_id" usageId=".../???.jsp">And then in your faces_config and your managed bean name is backingSystemStateBean and is located at path.to.bean.SystemState add a Session scope bean entry like this:
<managed-bean>
    <managed-bean-name>backingSystemStateBean</managed-bean-name>
    <managed-bean-class>path.to.bean.SystemState</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
    <managed-property>
      <property-name>bindings</property-name>
      <value>#{data.yourPageDef_Id}</value>
    </managed-property>

Backing Beans as session beans

All the beans on our web application are session scoped beans. Will there ever be any problems due to this? I do not have time to rewrite the beans in request scope.
Thanks.

I am sorry for not being clear. We use backing beans only to retreive and provide form data. I have noticed that all the developers on the team have used session as the scope for these beans. The reason seems to be usage of features such as partial page submits which work better if the bean is in session scope.
However I agree with you that this may cause uneccesary memory footprints. I am currently working on creating a request scoped backing bean that will get data for an Edit page. On submit, the Edit page needs to be re rendered. I need to figure out how to achieve this when the bean is in request scope.

Have a backing bean in request scope; need to access parameters sent to it

I have a request scope backing bean in my app, 'projectBean'. This has a property called 'id'.
/** in request scope in faces-config.xml */
projectBean {
    id               // set by the param from the previous page
    downloadAction() // activated by commandlink, depends on id
}There is another backing bean in session scope called 'projectListingBean', which has a dataTable that lists a bunch of projectBeans. In this 'projectListingBean', I can click on any row. That row, when clicked initializes a 'id' parameter, which is then passed to the new 'projectBean'. 'projectBean' then initializes itself based on the id.
In the jsp page backed by 'projectBean', I also have a link to download something specific to that 'projectBean'. Naturally enough, I have a commandlink with actionBinding to a method in my 'projectBean', downloadXXXAction().
The problem arises because the downloadXXX() method relies on a 'id'. Remember, this id was orinigally set 2 requests back from the datatable. Since the page backed by 'projectBean' is in request scope, the id is lost, and my method call doesn't work. I tried changing the scope of 'projectBean' to session, but JSF complains that I already setting the 'id' property as a param, I can't set the whole managed bean to something 'higher' like session.
Of course, the ideal fix to this probelm would be the ability to have beans in page scope, but what other ways (hacks??) are there to get around this?

Hi, I'm posting some code snippets if it helps with understanding the problem.
faces-config.xml:

<managed-bean>
     <managed-bean-name>projectListingBean</managed-bean-name>
     <managed-bean-scope>session</managed-bean-scope>
     <managed-property>
          <property-name>projectBeans</property-name>
          <property-class>java.util.List</property-class>
          <list-entries>
               <value-class>
                    com.sun.sleuth.omcmweb.view.bean.ProjectBean
               </value-class>
          </list-entries>
     </managed-property>
</managed-bean>

<managed-bean>
     <managed-bean-name>projectBean</managed-bean-name>
     <managed-bean-class>
     </managed-bean-class>
     <managed-bean-scope>request</managed-bean-scope>
     <managed-property>
          <property-name>projectId</property-name>
          <property-class>java.lang.String</property-class>
          <value>#{param.projectId}</value>
     </managed-property>
</managed-bean>projectlsting.jsp (page backed by projectListingBean)
<h:dataTable value="#{projectListingBean.projectBeans}"
     var="projectBean" ...>
     <h:column>
          <f:facet name="header">
          </f:facet>
          <h:commandLink action="#{projectListingBean.viewProjectSUmmary}">
               <h:outputText value="#{projectBean.projectId}" />
               <f:param name="projectId" value="#{projectBean.projectId}" />
          </h:commandLink>
     </h:column>
</h:dataTable>projectsummary.jsp (page backed by request scoped projectBean)
<h:commandLink action="#{projectBean.assessmentAction}" value="..." />
...Flow:
projectlisting.jsp (projectListingBean - session) -param id passed->
projectsummary.jsp (projectBean - request) -commandLink clicked and id lost-->
projectSummary.jsp (projectBean - request)

When exactly are request-scoped beans evicted from memory?

Hi,
I have a question about request-scoped JSF-managed beans and request-scoped HibernateFilter. It seems to me that request-scoped JSF beans actually outlive an HTTP request. Here's what I mean. Let's say I have a page backed by a request-scoped bean #{myBean} which displays a dataTable. a user can click on a row to perform some operation on row data.
I always thought the following to be true about lifecycle of JSF request-scoped bean:
1.User makes initial page request
-HTTP Request 1 (R1) comes in
     1. RestoreView encounters #{myBean} in page and constructs MyBean
     2. RenderResponse renders the page
-R1 is terminated, page is displayed, myBean is evicted from memory
2.User looks at the dataTable and clicks on a specific row (via commandLink). Now MyBean.action() is supposed to be
executed and perform some operation on row data:
-HTTP R2 comes in
     1.MyBean is constructed again (e.g. not using same instance as in R1). (THIS IS KEY!)
     2.myBean.action() is executed
-R2 is terminated, myBean is again evicted from memory
Is the above understanding correct?
Or does myBean instance (and its' properties) remain in appserver memory between R1 and R2 and R2 actually uses the
same instance of myBean?
If scenario above is correct, then I have a strange problem:
-when performing myBean.action() during R2 on rowData (which is instance of MyHibernateBean) I get a
HibernateException stating that bean isn't associated with a Hibernate Session. This can only happen if the lifecycle of the object and its' parent myBean exceeded that of R1. That is because I have a Hibernate Servlet
Filter that a) start a Hibernate Transaction on incoming request and b) commits it on the way out.
Here's pseudo-code for myBean:
public class MyBean {
    public static String HANDLE = "#{myBean}";
    //getters setters omitted
    //used as 'value' in dataTable
    private List<MyHibernateBean> dataBeans;
    //dataTable binding
    private UIData tableData;
    public MyBean() {
    public String action() {
        //read children & modify state of a hibernate bean
        MyHibernateBean dataBean = (MyHibernateBean) this.tableData.getRowData();
        HibernateUtil.getCurrentSession().refresh(dataBean); //seems necessary as dataBean instance deemed 'stale'
        dataBean.getChildCollection(); //will fail without line above
        return "toSomewhereElse";
}

By the way, I have an hypothesis why this does not work...
The datatable values MUST be specified using a value binding expression. When the restoreState method for the component is called, JSF attempts to use the VB expression to get the table values. When the managed bean is not found, it creates a new (empty) one and the world ends (actually it just returns back to the original page because it cannot figure out what to do)

Calling Backing Bean Method with h:outputLink

Is there a way to call a backing bean using h:outputLink isntead of h:commandLink ?

No, you can't. You however can just let it point to a JSF page and make use of the constructor of the involved request scoped managed bean.

Calling from an EJB into a JSF Backing Bean

Hello all,
I'm looking for some help in making calls from an EJB into a Backing Bean (the converse is fairly straightforward). My basic question is: what is regarded as the best way to do this?
However, for anybody who's interested, I'll describe what I've been trying...
Here's my situation (I'm working with OC4J 10.1.3.2). I have a simple application-scoped backing bean:
   public class BackingBean implements SimpleInterface, Serializable {
       private String greeting = "Hello, World";
       private SessionEJBRemote blBeanRemote = null;
       public BackingBean() {
           // get hold of EJB
           // [ ... code to obtain EJB's remote interface snipped ... ]
           // set the callback with the EJB
           try {
               blBeanRemote.setCallback(this);
           } catch (Exception ex) {
               ex.printStackTrace();
       // methods to manipulate the greeting string
       public String getGreeting() {
           return greeting;
       public void setGreeting(String greeting) {
           this.greeting = greeting;
   }SimpleInterface, which my Backing Bean implements is, well, a simple interface:
   public interface SimpleInterface {
       public void setGreeting(String greeting);
   }And my EJB is also pretty straightforward:
   @Stateful(name="SessionEJB")
   public class SessionEJBBean implements SessionEJBRemote, SessionEJBLocal {
       private SimpleInterface callback = null;
       public void setCallback(SimpleInterface callback) {
           this.callback = callback;
           callback.setGreeting("Goodbye, World");
   }Now, by using SimpleInterface, my intention was to ensure a one-way dependency: i.e. the JSF-level code would depend on the EJB-level code, but not vice versa.
However, my experimentation has shown that when I make the call to blBeanRemote.setCallback, the parameter appears to be passed by value rather than by reference. This means firstly that, at runtime, by EJB needs to have access to my backing bean class and secondly, that the call to callback.setGreeting has no effect.
Can anybody suggest how to work around this? Is it possible to pass the backing bean by reference? Is there a better way to achieve this callback? I appreciate that these questions might be more general Java/AppServer queries rather than JSF-specific ones - but hopefully this is something that all you JSF experts have encountered before.
(Incidentally, I realise that what I'm doing in this example is pointless - what I'm building towards is using the ICEFaces framework to have the EJBs prod a backing bean which will in turn cause a user's browser to rerender.)
Many thanks - any help very much appreciated!
Alistair.

Hi Raymond - yes, you've pretty much got that spot on: an event occurs (say receipt of a JMS message - which is spontaneous, as far as the users are concerned). As a result of that event, the client's view (in their browser) needs to be re-rendered.
ICEFaces uses the AJAX technique to allow server-pushes, and rather than refreshing the whole page it uses "Direct-to-DOM" rendering to maninpulate the page components. If you've not come across it, and you're interested, then there are some pretty interesting demos here: http://www.icefaces.org/main/demos/ - the "chat" feature of the Auction Monitor demo (if you open it up in two browsers) is the nearest to the effect I'm looking for.
The Auction Monitor demo uses a number of session-scoped beans, each implementing the ICEFaces "Renderable" interface, and each of which registers itself with an application-scoped bean. The application-scoped bean can thus iterate through each of the session-scoped beans and cause the corresponding browser to refresh.
Unfortunately, in the Auction Monitor demo, the entry point is always from a browser - albeit the result is then mirrored across all connected browsers. I haven't found any examples of this processing being driven by an external event, hence my experimentation in this area!

Role of backing beans in MVC design

Hello,
yet another JSF/MVC question. In short, I would like to know what the role of the backing beans are in an MVC design with JSF. The most simple answer would be that they are just the Controllers. But that doesn't seem enough.
Suppose I have an application model, call it Ma, which is just an interface that represents a use case in Java. Ma doesn't know anything about a view or controller, it is just domain logic with application-specific state and behavior added. Now,
- my backing bean uses Ma as its Model, acting as a true Controller by delegating requests to it
- my backing bean also adds view-specific state (show/hide stuff and it also returns a List<SelectItem> for example) that I can't put on Ma, so it also acts as a view model Mv
So, I could argue that I have an Mv-V-C design, where the backing bean is both C and Mv. My user interface V only queries Mv for its state.
Usually I read that V and C are considered to be very tightly coupled, so then I would have an Ma-V-C design with the backing bean being C and part of V.
Is it just a question of terminology or point of view, expressing the same idea twice?

The way I think about it is that there are multiple layers of MVC.This kind of refers to my point-of-view question. So let's try two of them.
The view itself can be thought of as containing MVC elements.When only looking at JSF (presentation layer) we have:
- Model: backing beans (view model Mv)
- View: view root and JSPs (query backing beans for state)
- Controller: Faces servlet (dispatches requests to backing beans)
In my "enterprise" quality applications, I will have three distinct layers.Taking a step back, let's look at the application layer (your "control layer", application logic behind interface) and the presentation layer.
Then:
- Model: application model Ma in application layer
- View: backing bean (associated with UI components)
- Controller: backing bean (dispatches requests to Ma)
Agree?
It's interesting that you call my application layer "control layer" since it seems more like a model to me, especiallly when you say:
The control layer consists of business logic interfaces and their implementations.This said, the objects in this application layer do have some controller functionality as they orchestrate the interactions with the underlying domain model, just llike the backing beans do with the application model. So maybe you can take another step back and consider these application logic interfaces as the View and Controller for the underlying domain model. That is: in a layered MVC design every M can become the VC for an underlying (more general) layer?
And I have seen this taken to extremes.Perhaps that's what I'm doing here :)

PLZ Help: how to get value of a request scoped Bean/Attribute in JSF ?!!!

hi,
I noticed this part of code to retrieve session scoped beans/vars in an ActionListener or other jsf classes, but it does not work for request scoped beans/vars :( what's the problem then ? what shall i do ?
Type var = (Type)Util.getValueBinding("myBeanInRequest")).getValue(context);
I have also set that getPhaseId() returns UPDATE_MODEL_VALUES or APPLY_REQUEST_VALUES.
Any comment or idea ?

I have declared my Bean in my JSP page not in the
faces-config.xml. Does this make any problem ? Also I
have tried the way you told me as well, but still the
returned attribute is null.
P.S. My bean is declared in my JSP page this way:
<jsp:useBean id="newSurveyVar" class="SurveyModel"
scope="request" />
This declaration causes the SurveyModel instance to be created in request scope when the page is rendered, but that doesn't help you when the form is submitted -- that is going to happen on the next request (so the request attribute created here goes away). Basically, <jsp:useBean> is not typically going to be useful for request scope attributes (it's ok for session or application scope, though).
and further I have this jsf code:
<h:command_button label="Create" commandName="create"
action="create" >
<f:action_listener
r type="CreateNewSurveyActionListener"/>
</h:command_button>
and this is my
CreateNewSurveyActionListener.processAction(ActionEvent
e) {
if (actionCommand.equals("create_the_survey")) {
FacesContext context =
t = FacesContext.getCurrentInstance();
SurveyModel survey =
y =
(SurveyModel)(Util.getValueBinding("newSurveyVar")).get
alue(context);
if (survey==null) // returns true :(((
And since I've declared my beans here there is nothing
special declared in my faces-config.xml
For me again it is really strange why it is not
working !!!
Any idea ? Because the event listener is fired in a separate request, so the one you created in the page is gone.
This is why the managed bean creation facility was created. If your component contains a valueRef that points at the bean name (or you evaluate a ValueBinding as illustrated earlier in the responses to your question), then the bean will get instantiated during the processing of the form submit.
Craig McClanahan

Cannot reliably use request.getRequestURL() in my backing bean

I am using jDev 11.1.2.3.0.
In my backing bean to my ADF JSF page fragment I get mixed results from different web browsers when trying to retrieve a URL from the request object. The java code I use in my bean is like this:
FacesContext fc = FacesContext.getCurrentInstance();
HttpServletRequest request = (HttpServletRequest)fc.getExternalContext().getRequest();
String URL = request.getRequestURL().toString();
Depending on whether I use IE, Firefox or Chrome, sometimes the URL = null. What's wierder is that different computers in my office get different results. One computer can get URL = null in IE and FF, and another would get null using Chrome and IE. It's so bizzare, I don't even know where to start debugging this issue.
But I'm wondering if it's the way I am retrieving the request object using request = (HttpServletRequest)fc.getExternalContext().getRequest(); Is this the right way to get the request object?

Hi,
if you are in a page fragment then the request is partial anyway. So can you give us an idea of what the use case is for which you need the URL ? Maybe its easier to fix the desired use case implementation then to fix access to the URL just to find out you cannot use the result (the URL is not identifying the page fragment and thus doesn't allow redirects or bookmarks)
Frank

Problem with Commit button When Backing bean is in Request Scope...

HI Everybody,
I have a Backing Bean in request scope having over 1000 lines of code, And in my JSPX page I have a table binding with a view object and At run time when user select the row in table and click the edit button so user will be able to edit that selected row in the same table at run time.. but the problem is : when the user enters some data in the Editable inputTexts and then clicks save(Commit), then the save button doesn't work..but when i delete any selected row and then press save then it is working fine..
And to test it in Session scope i made another sample page where every thing is working very fine..
Now i want to know What is the difference between Session scope and request scope bean...
And is there any solution to Save editable input text in Request scope?.
Also want to know that is it safe to set the scope of my main bean class to session scope without effecting the current running functionality? which is having over 1000 lines of code and lot of component has been placed...
Please help me to resolve this problem...
Thanks in Advance to all of you
Fizzz..

Hi Frank...
In my code i used almost same logic as Andrejus Baranovskis has explained in his Editable Table example...
You can refer that example to see what problem I'm facing...
http://andrejusb.blogspot.com/2007/04/create-edit-and-delete-operations-in.html
The Bean Scope in this Example is Session scope...Save button is working fine...
But as i Change the bean scope to Request scope then Save button is not working for Edit but it is working for Delete Action very well..
I want that save button should work also for Edit action in Request Scope..
Please Make me understand that why it is happened like that..
and help me to find the solution..
and Also if you have a better document to Explain the life cycle of Application in Different Bean Scope...So please provide me that Doc to me...
It would be a great help for me to understand the concept of session...
Thanks Frank
Fizzz...

Re: Ajax request handled by backing bean

I have a servlet that is handling an Ajax request for a page. This works very well, however i am struggling with using an event handler in my backing bean to handle this request. It seems like the reqest does not get routed to the backing bean when i try to use it as the url.
Any guidance would be appreciated.
Thanks

To execute a backing bean method from your servlet, you must first make the FacesContext available to your doGet or doPost method. To learn how to make the FacesContext available, look at the init method (and the doGet method) in the 5655_ajaxcreator/ajaxcreator/exercises/exercise1/EmployeeValidationServlet.java in the JavaOne Hands-On Lab 5655. There is a link to the Lab 5655 zip file on this page:
http://developers.sun.com/prodtech/javatools/jscreator/community/javaone/creatorteam.html
Once you have emulated the EmployeeValidationServlet.init method to make the FacesContext available to your doGet or doPost method, use code like the following to execute your backing bean method and write out a response:
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// Acquire the FacesContext instance for this request
FacesContext context =
facesContextFactory.getFacesContext(servletConfig.getServletContext(), request,
response, lifecycle);
MethodBinding mb = context.getApplication().
createMethodBinding(...);
mb.invoke(context, new Object[]{...});
response.setContentType("text/xml");
response.setHeader("Pragma", "No-Cache");
response.setHeader("Cache-Control", "no-cache,no-store,max-age=0");
response.setDateHeader("Expires", 1);
response.getWriter().write("<message>hello world</message>");
}

How to decide when to keep backing bean in request and session.Pros/cons

How to decide when to keep backing bean in request and session.Pros/cons

Depends on where the bean data must be available. Start with request scope. If you need the data in session scope, then think twice about impacts (memory usage, multiple browser tabs, etc) unless the data is obviously targeted on the session scope (loggedin user, user settings, dropdown data, etc).

Can I change the request params in my backing bean?

I want to change the request params in the backing bean method.
For example:
<h:commandLink value="test" action"myBean.test">
<f:param name="a" value="1" />
</h:commandLink>
When user click the link, myBean.test() will be invoked.
Can I change the request param values in myBean.test()?
I mean, if I can change the value of "a" to "2" or add a new param?
Thanks!

I'm not sure if You can change any request parameters...
You can set e.g. a request attribute in the case that You get the request object from the faces context and set the attribute.
something like this...
FacesContext fc = FacesContext.getCurrentInstance();
HttpServletRequest req = HttpServletRequest)fc.getExternalContext().getRequest();
req.getParameter("id");
req.setAttribute("id", new Integer(2));

Reconstruction of request scoped backing beans

Similar Messages

Maybe you are looking for