1

I have a check box in my application and I want to call selectPlan method to execute when user select the check box

But when ever I select the check box it call the @PostConstruct method before the selectPlan method.

This leads to unwanted calls to back end as I have written some functions to populate data when page load in the @PostConstruct

<td>
      <h:selectBooleanCheckbox value="#{plan.checked}">
         <f:ajax listener="#{planOverlay.selectPlan}" render=":overlayForm:myTable"/>
      </h:selectBooleanCheckbox>
</td>

Below is the bean class

 import javax.faces.bean.ManagedBean;
 import javax.faces.bean.ViewScoped;

 @ManagedBean(name = "planOverlay")
 @ViewScoped
 public class PlanOverlayBean extends OverlayBean {

    @PostConstruct
    public void init() {
       super.init();

       loadPlansFrom_DB();
    }

    public void selectPlan(AjaxBehaviorEvent event) throws Exception {
       getOverlay().getService().setSelectedPlan(rowdata);
    }
}
ever alian
  • 1,028
  • 3
  • 15
  • 45
  • @BalusC I checked this but I confirm my `ViewScope` is using `import javax.faces.bean.ViewScoped;` – ever alian May 08 '15 at 14:47
  • Who's managing the bean? That annotation would only work along with JSF specific `@ManagedBean` from same package. – BalusC May 08 '15 at 14:48
  • @BalusC I updated the full class details including import statements – ever alian May 08 '15 at 15:04
  • Which JSF impl/version? Does the problem also manifest when you've **only** a `` in a test page? – BalusC May 08 '15 at 15:04
  • @BalusC Yes, Still it loads the bean. – ever alian May 08 '15 at 15:17
  • Which JSF impl/version? – BalusC May 08 '15 at 15:18
  • @BalusC I'm not sure how to check the version correctly. I think this is `jsf 2.0`. I found a `faces-config.xml` also in `WEB-INF` folder – ever alian May 08 '15 at 15:34
  • Check JSF version: http://stackoverflow.com/a/13125869/4074715 – Predrag Maric May 08 '15 at 15:53
  • @BalusC It prints The version as 1.0.0.0_2-1 when I use `FacesContext.class.getPackage().getImplementationVersion()` – ever alian May 09 '15 at 14:46
  • Looks like a server-modified/managed JSF 2.1 implementation. The exact JSF 2.1 implementation and version should then be determined based on exact server make/version (provided you didn't upgrade/change the server-bundled JSF). I only don't suspect a JSF impl/version specific bug anymore as that would otherwise obviously affect all other users of same server make/version (and being able to use @ViewScoped is a very very important feature). Perhaps you're victim of classpath pollution? Do you have any JSF-related JARs in /WEB-INF/lib? – BalusC May 09 '15 at 14:47
  • @BalusC I have `jsf-api.jar, jsf-impl.jar` inside the `WEB-INF/lib` and also these jars in the same place `httpclient-4.1.2.jar, httpcore-4.1.2.jar, json-lib-2.4-jdk15.jar, primefaces-3.4.1.jar, tomahawk20-1.1.14.jar,ezmorph-1.0.6.jar, commons-io-2.1.jar, commons-fileupload-1.2.2.jar` – ever alian May 09 '15 at 16:37
  • Which server impl/version? I have the impression that it already ships with JSF out the box given the odd implementation version string and the absence of JSTL JAR file in /WEB-INF/lib. In such case you should absolutely not have JSF API/impl JARs in /WEB-INF/lib, unless you intend to upgrade the server-bundled JSF from the webapp on (but that requires some specific settings and therefore knowledge of it which you didn't cover anywhere in the question) – BalusC May 09 '15 at 17:32
  • @BalusC My server version is Oracle WebLogic 12C. Please help me how can I solve this issue? – ever alian May 10 '15 at 15:41
  • WebLogic as being a Java EE container already ships with JSF bundled as part of Java EE. Remove the both JSF JARs from /WEB-INF/lib and retry. They're colliding with WebLogic-bundled JSF which may expose in this kind of problems. – BalusC May 10 '15 at 16:16
  • @BalusC I removed both jar from said location but still the issue is same. – ever alian May 11 '15 at 01:57
  • @BalusC Isn't this the same as [this](http://stackoverflow.com/questions/2797231/why-does-postconstruct-callback-fire-every-time-even-though-bean-is-viewscoped) error – ever alian May 11 '15 at 04:12
  • You're dealing with two different beans here: `plan` and `planOverlay`. Which bean's `@PostConstruct` is being called? – kolossus May 11 '15 at 18:51
  • @kolossus The `plan` is an object inside the `planOverlay` bean. The `@PostConstruct` is is being call to `planOverlay` bean. Confirmed. – ever alian May 12 '15 at 02:00
  • if `plan` is inside `planOverlay`, why is it not being referenced as `planOverlay.plan`? Is the `f:ajax` the first point at which `planOverlay` is being referenced on that page? If that's the case, I would expect the `@PostConstruct` to be called first there – kolossus May 12 '15 at 04:01
  • @kolossus When my page load I want to retrieve all the plans from DB. This code is inside the `@PostConstruct`. So I don't want to call it over and over. This is the issue. `f:ajax` call is to set the plan which user select. – ever alian May 12 '15 at 06:52
  • @BalusC Don't you help me further? I'm still having this dilemma – ever alian May 12 '15 at 10:04
  • The problem is not visible in the information provided so far. It works just fine for me when tested in a blank playground project with most minimal configuration and using most recent versions. – BalusC May 12 '15 at 10:09
  • @BalusC isn't it relate to [this] (http://stackoverflow.com/questions/2797231/why-does-postconstruct-callback-fire-every-time-even-though-bean-is-viewscoped) ? – ever alian May 12 '15 at 10:28
  • I asked you "Does the problem also manifest when you've only a `` in a test page?". You answered "Yes". So that problem isn't related. – BalusC May 12 '15 at 10:39
  • @BalusC I'm sorry I didn't see that this should done in a test page. Today I tried with another bean and a page in the same project. It is not calling the `@PostConstruct` again. what could be the reason to call it in that particular page only? – ever alian May 13 '15 at 11:52
  • Well, create a MCVE. If you have no clue how to do that, carefully read http://stackoverflow.com/help/mcve and http://stackoverflow.com/tags/jsf/info – BalusC May 13 '15 at 19:15

2 Answers2

1

To avoid that case,we should check if it is postback or ajaxRequest. If your bean is viewScoped,you can add below code to your post-construct method.

Maybe it is not the best case but it works.

Also you can use JSF 2 PreRenderViewEvent for some initialization for bean.

    if (!FacesContext.getCurrentInstance().isPostback()) {
            if (!FacesContext.getCurrentInstance().getPartialViewContext().isAjaxRequest()) {
       //Some initialization  
        } 
}
mstzn
  • 2,881
  • 3
  • 25
  • 37
  • A view scoped bean should just not be recreated on every ajax request on the same view. This is not the normal behavior. – BalusC May 08 '15 at 11:36
  • I agree with you.I used that control for some primefaces components which causes recreated on every ajax request on the same view. – mstzn May 08 '15 at 13:08
0

You should make your bean session scoped, so the @PostConstruct gets called only once per session. When bean is request scoped, like yours is judging by the behavior, it is created for each request which results in init() getting called also for each request.

EDIT

The suggestion was based on the assumption that the bean is request scoped, and that init() should be called once per session/view. OP's comment proved the assumption wrong.

Predrag Maric
  • 23,938
  • 5
  • 52
  • 68
  • At present the bean scope is `ViewScoped`. So it should work right? as I am in the same view. – ever alian May 08 '15 at 10:58
  • It should work if it is view scoped, but it behaves like it is request scoped. How did you configure its scope? Can you try, just for debugging purpose, with session scope? – Predrag Maric May 08 '15 at 11:03
  • 2
    Making it session scoped is bad advice. – BalusC May 08 '15 at 11:07
  • @BalusC I know, I said just for debugging purpose, to check if maybe scope configuration is wrong – Predrag Maric May 08 '15 at 11:09
  • @PredragMaric, then state so... Mention that it might be that the scope is to short and refer to several existing SO posts about scopes. Beginners tend to take statements like your in your answer as 'how it should be done'. And with `ViewScoped` it can even be the 'wrong' one – Kukeltje May 08 '15 at 12:16
  • @Kukeltje I wrote that it should work with view scope, and I also wrote that session scope should be tried just for debugging purposes. If you have other idea how an answer to this question should look like, post your own. – Predrag Maric May 08 '15 at 12:37
  • @PredragMaric I update the question. Added the the class details and how I define the `ViewScope`. – ever alian May 08 '15 at 14:57
  • @everalian Strange. Can you check if session is kept between HTTP calls to the server? Check if session cookies are sent along with each request. – Predrag Maric May 08 '15 at 15:05
  • @PredragMaric how to check the things you said? – ever alian May 08 '15 at 15:09
  • @everalian From browser. If you are using Chrome, press F12 and switch to Network tab. When you click on checkbox, a new request will be displayed in the list below. Click on it, then Cookies tab, it will display what cookies are sent to the server with the request. Check if there is a cookie named `JSESSIONID`. Similar instructions for other browsers. – Predrag Maric May 08 '15 at 15:14
  • @PredragMaric `Cookies` tab is empty. But I found it in the `Header` Tab `JSESSIONID=j6GcVMJDts90T42DXhH49xCbZmXnKrH2tVhc5FqVQSvLQbL2Ghql!-928136128` – ever alian May 08 '15 at 15:24
  • @everalian Does the value change with each request? – Predrag Maric May 08 '15 at 15:36
  • @PredragMaric No, Value is same. But pls note. I change the code to `` now as requested by `BalusC` – ever alian May 08 '15 at 15:44
  • @everalian I'm out of ideas, sorry. And I don't have a project at my hands right now where I could test this. – Predrag Maric May 08 '15 at 15:53
  • @PredragMaric No worries, Thanks for the effort so far. May I know what are you trying to isolate with the jsessionid? what if it has different ID per request? – ever alian May 08 '15 at 16:06
  • @everalian I read that some web containers use different session ids to each request for unauthenticated users, as a measure against session fixation attacks. I think that would explain the behavior you are seeing. – Predrag Maric May 08 '15 at 21:32