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.


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