> -----Original Message-----
> From: Heath Borders [mailto:[EMAIL PROTECTED] 
> Subject: Re: Warning messages
> Well, the reason I would want to skip it is because of the 
> performance hit it will cause.
> For every UIInput, for instance, we would have to traverse up 
> the tree to find the containing UIForm.

Ah yes.. In that case doing isWarnEnabled() before looking up the form
is definitely useful.

Kalle

> On Mon, 21 Mar 2005 14:03:18 -0800, Korhonen, Kalle 
> <[EMAIL PROTECTED]> wrote:
> > > On Mon, 21 Mar 2005 21:06:46 +0100, Manfred Geiler 
> > > <[EMAIL PROTECTED]> wrote:
> > > > Yes, or better isWarnEnabled(). Warn level is probably the best 
> > > > for this kind of warnings.
> > 
> > ... and I wouldn't even bother doing isWarnEnabled() check. Those
> > enabled() methods are basically only provided to skip over 
> unnecessary 
> > string concatenation. Really useful for debug() logging but 
> not so for 
> > warn messages, which there usually are a lot less and they 
> are almost 
> > always enabled anyways.
> > 
> > Kalle
> > 
> > > >
> > > > Manfred
> > > >
> > > > On Mon, 21 Mar 2005 14:00:14 -0600, Heath Borders 
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > I guess if I just did a check for isDebugEnabled() 
> first before 
> > > > > going through the hassle of searching for a parent form, it 
> > > > > would have the same result.
> > > > >
> > > > >
> > > > > On Mon, 21 Mar 2005 11:39:34 -0800, Korhonen, Kalle
> > > <[EMAIL PROTECTED]> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Heath Borders [mailto:[EMAIL PROTECTED]
> > > > > > > Subject: Warning messages
> > > > > > > Do you guys think we should have warning messages for
> > > things we
> > > > > > > know will cause components to not function properly, and 
> > > > > > > then have a variable in the web.xml to turn it off?
> > > > > > > We could have warning messages for all components 
> that need 
> > > > > > > forms, or for components using the "for" attribute
> > > that cannot
> > > > > > > find their parent component, etc.
> > > > > > > These could all be enabled by default.
> > > > > > > Then, there could be a context-variable named 
> > > > > > > "org.apache.myfaces.warnings" which could be set to
> > > "false" or "true"
> > > > > > > to turn it off or on.
> > > > > >
> > > > > > Otherwise, I'm definitely for more logging and warning
> > > messages,
> > > > > > but please let's not add a new context-variable for 
> this. Even 
> > > > > > newbies should be able to configure java/commons/log4j
> > > logging and
> > > > > > if not, they are much better off with learning to
> > > configure those
> > > > > > properly than some other custom logging properties. I
> > > can also see
> > > > > > that that pretty soon your simple and harmless 
> warnings on/off 
> > > > > > would be changed to logging level, then a few more settings 
> > > > > > for redirecting etc... So let's keep logging 
> configuration in 
> > > > > > the standard logging properties. Surely we can provide
> > > default logging
> > > > > > properties where warnings are enabled (and usually
> > > anything above info is logged by default anyways).
> > > > > >
> > > > > > Kalle
> > > > > >
> > > > >
> > > > > --
> > > > > -Heath Borders-Wing
> > > > > [EMAIL PROTECTED]
> > > > >
> > > >
> > >
> > >
> > > --
> > > -Heath Borders-Wing
> > > [EMAIL PROTECTED]
> > >
> > 
> 
> 
> --
> -Heath Borders-Wing
> [EMAIL PROTECTED]
> 

Reply via email to