Yes, that exactly is the problem. Data can be uninitialized if the parent should not be rendered (or it will be lazy initialized on each request if BackingBean is request scope and not saved in the request).
Therefore I would prefer to skip all components that should not be rendered, as you mentioned. Michael -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Montag, 11. Februar 2008 13:14 To: MyFaces Discussion Subject: Re: changing myfaces loglevel to debug causes different behavior ---- Simon Kitching <[EMAIL PROTECTED]> schrieb: > ---- Michael Heinen <[EMAIL PROTECTED]> schrieb: > > I noticed today strange behavior if I change the loglevel for myfaces. > > > > Some getters of my backing beans are called although the rendered > > attribute of a parent component is false. > I don't see why invoking attribute getters should break an application. Hmm..missed your "rendered is false" statement above. Yes, it might be a bit unreasonable to call getters on attributes of components that are not rendered. The EL expressions do often point to uninitialised data in that case. In that situation, ---- Simon Kitching <[EMAIL PROTECTED]> schrieb: > ---- Michael Heinen <[EMAIL PROTECTED]> schrieb: > > I noticed today strange behavior if I change the loglevel for myfaces. > > > > Some getters of my backing beans are called although the rendered > > attribute of a parent component is false. > I don't see why invoking attribute getters should break an application. Hmm..missed your "rendered is false" statement above. Yes, it does seem a bit unreasonable to call getters on attributes of components that are not rendered. The EL expressions do often point to uninitialised data in that case. In that situation, perhaps DebugUtils should just print out the EL statement for each attribute, rather than evaluating it? We cannot actually get EL expressions via the Attributes map, but can get them via UIComponent.getValueBinding(). There is a slight danger that an attribute manually inserted into the attributes map is actually hiding the EL expression bound to the same name, but that is pretty remote. Or just skip all attribute info for non-rendered components.. Regards, Simonperhaps DebugUtils should just print out the EL statement for each attribute, rather than evaluating it? We cannot actually get EL expressions via the Attributes map, but can get them via UIComponent.getValueBinding(). There is a slight danger that an attribute manually inserted into the attributes map is actually hiding the EL expression bound to the same name, but that is pretty remote. Or just skip all attribute info for non-rendered components.. Regards, Simon
