If your bean is Request Scoped, then it will execute @PostConstruct
every request. My first thought would be to use a Session Scoped bean,
or to implement a custom caching solution.
--Lincoln
On Thu, 2009-04-09 at 17:12 -0700, webtier_at_javadesktop.org wrote:
> 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 <commandLink action="#{anotherFB.myCommand}">
> * 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...
> Thanks!
> [Message sent by forum member 'bouteill' (bouteill)]
>
> http://forums.java.net/jive/thread.jspa?messageID=341444
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: webtier-help_at_glassfish.dev.java.net
>