> 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 think there is a misunderstanding here. An h:commandLink is the same as an h:commandButton. The difference is only in how they are presented on the screen. A commandLink submits all the data back to the server, which is causing your beans to be used. If this is in a header area, perhaps putting the h:commandLink in its own form will prevent your problem?
I responded to this thread on another email list, and suggested pageSession or conversation scope for caching. While conversation scope may be more difficult to guarantee that it gets cleaned up, pageSession is associated with the UIViewRoot, so it gets managed automatically with the page (note: you don't have to have JSFT or JSF 2.0 to use this, you can do viewRoot.getAttributes().get/put()).
Now that I realize they want a get request + an action (not a h:commandLink or h:outputLink), it might be worth looking at restfaces (
https://restfaces.dev.java.net/) or implementing similar behavior. This allows actions to be invoked on GET requests.
All that said... their design seems to be fundamentally flawed as it will make Ajax or even full page refreshes perform poorly if they require their data to be recalculated every (refresh) request. Perhaps someone a little consulting or training at the customer site would go a long way, there are plenty of good resources available that would be able to clean this up.
Good luck!
Ken
[Message sent by forum member 'kenpaulsen' (kenpaulsen)]
http://forums.java.net/jive/thread.jspa?messageID=342170