How to avoid @PostConstruct on page Faces beans during postback?
Hello, we're using GlassFishV2/JSAS9.1 with Mojarra 1.2_04-b22-p05 for a large project, and experiencing performance issues on form-less JSF commands when used in conjonction with @PostConstruct annotations. I feel this is an architectural issue I'm not able to resolve though, so I was wondering if anyone could shed some light on whether I'm missing something, there is some known workaround or it's a known JSF problem?
The scenario is as follows:
* Page my.jsp references Faces Beans MyFB.java
* MyFB has @PostContruct method, which execute expensive logic to initialize the data model before rendering phase
* my.jsp has a
* anotherFB.myCommand executes some logic and nav to another.jsp
Now what seems to happen is that when we click on the commandLink, JSF does a postback to the same URL, instantiates MyFB, calls @PostConstruct on MyFB, and then instantiate anotherFB to call myCommand on it and nav to another.jsp
In this situation, the expensive @PostConstruct logic to prepare data for rendering on my.jsp is executed although it is totally useless to the use case and hurts site performance a lot.
I tried to use immediate="true" attribute, but it doesn't seem to prevent the @PostConstruct...
In the case of a JSF form commandButton on the same bean, I can see how that would be necessary, but for a commandLink to another bean, why is JSF calling @PostConstruct on the previous page beans??
I seem to be able to workaround this problem doing an if (getFacesContext().getRenderKit().getResponseStateManager().isPostback(getFacesContext()) in our @PostConstruct method and then make sure all the getters are NPE-safe, but if the commandLink is in a common include file, I'd then have to do this in every single beans within my app, which is not reasonable IMHO.
Has anyone else experienced this problem? Or even maybe worked around it somehow?
I'm curious if I'm missing something or if this is a major JSF architectural issue...