Somewhere (I don't have the MyFaces source) in the MakeAlias component, it appears they are using EL #{} which points to one of your MB's which is evaluated when they're doing the restore view. Perhaps near:
at org.apache.myfaces.custom.aliasbean.Alias.make(Alias.java:137)
This is not common in my experience... but I know nothing of the makeAlias component. Perhaps that is exactly what they intend to do in order to alias another component (which may require resolving it at unusual times, such as here). If you look at their source, I think you'll probably find your answer, especially if it's well documented.
The applyRequestValues evaluation of the rendered property is quite common. If a component is not rendered, most components will not attempt to apply their submitted values for good reason. The side-effect here is that MB's may be referenced when you don't want them to be.
Is there a way to avoid this? Sure, here are a couple options:
1) You can avoid using MB's in these 2 cases directly. For example, set a pageSession variable (i.e. a view attribute). This will still persist accross requests, not use session, and not invoke any MB's. To do this set the value(s) you need access to in pageSession (if your environment supports that), or perhaps find a way to reference attributes on the viewRoot... something like: #{view.attributes['foo']}. You can initialize foo in your @postconstruct.
2) You can use a lazy or proxy MB. In other words, use a light-weight one that avoids the expensive calls unless that data is absolutely necessary. Not sure if this is an option in your case. Or perhaps you can simply re-organize your MB methods to make the rendered / other values on a less demanding MB (again not sure if this will work for you). (Just saw Ryan's response... which is the same as this.)
Good luck!
Ken
[Message sent by forum member 'kenpaulsen' (kenpaulsen)]
http://forums.java.net/jive/thread.jspa?messageID=343419