myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Broekelmann, Mathias" <MBroekelm...@PSI.DE>
Subject RE: [jira] Commented: (MYFACES-246) The WARN level log statement in VariableResolverImpl.resolveVariable should be DEBUG level
Date Thu, 26 May 2005 09:11:17 GMT
I´ve come across to this message some time ago. I would like to make an improvement to alias
bean component to allow nested alias bean component to overwrite an existing bean in their
scope and putting back the hidden value if the scope of the alias is away.

To make this possible the alias component have to look at the existing value for the alias
name which may of course not be used before which produces the warning message from the variable
resolver.

So I would agree to use the debug level or at least to test if the level which is used is
enabled:

if(log.isDebugEnabled())
{
	log.debug(...);
}

Or

if(log.isWarnEnabled())
{
	log.warn(...);
}

Testing the log level before logging should be used for performance reasons.

Mathias

> -----Original Message-----
> From: Martin Marinschek [mailto:martin.marinschek@gmail.com] 
> Sent: Thursday, May 26, 2005 10:54 AM
> To: MyFaces Development
> Subject: Re: [jira] Commented: (MYFACES-246) The WARN level 
> log statement in VariableResolverImpl.resolveVariable should 
> be DEBUG level
> 
> 
> Hmmm...
> 
> I would say that attributes of components should only be evaluated in
> the context in which they exist - that would mean that the call to the
> isRendered attribute is wrong in this case, if it is not executed
> while a datatable iteration is happening.
> 
> What would you say?
> 
> regards,
> 
> Martin
> 
> On 5/26/05, Martin Marinschek (JIRA) 
> <myfaces-dev@incubator.apache.org> wrote:
> >      [ 
> http://issues.apache.org/jira/browse/MYFACES-246?page=comments
> #action_66323 ]
> > 
> > Martin Marinschek commented on MYFACES-246:
> > -------------------------------------------
> > 
> > I don't understand your problem well enough, I think. I use 
> dataTable and the row variables for binding all the time and 
> never have WARN messages logged out (and I think my log4j is 
> instantiated properly ;)
> > 
> > Can you show the constellation in which the problem occurs?
> > 
> > regards,
> > 
> > Martin
> > 
> > > The WARN level log statement in 
> VariableResolverImpl.resolveVariable should be DEBUG level
> > > 
> --------------------------------------------------------------
> ----------------------------
> > >
> > >          Key: MYFACES-246
> > >          URL: http://issues.apache.org/jira/browse/MYFACES-246
> > >      Project: MyFaces
> > >         Type: Improvement
> > >     Versions: 1.0.9 beta
> > >  Environment: WinXP, Pentium4, TomCat 5, MyFaces 1.0.9
> > >     Reporter: Kevin Roast
> > >     Assignee: Martin Marinschek
> > >     Priority: Minor
> > 
> > >
> > > The WARN level log statement in 
> VariableResolverImpl.resolveVariable should be DEBUG level.
> > > The reason for this is that if you use DataTable or any 
> other custom component that uses temporary variables for 
> binding (e.g. Row variables in a datatable) then the 
> variables resolver will spit out WARN level statements like this:
> > > WARN  [VariableResolverImpl] Variable 'r' could not be resolved.
> > > Because the variable is no longer in Scope it cannot be 
> resolved - this fine, but the WARN level is probably too 
> high, it could cause a minor performance issue in large apps 
> as the WARN output String is always constructed with an If 
> statement surrounding it to check the log level.
> > 
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the 
> administrators:
> >    http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> >    http://www.atlassian.com/software/jira
> > 
> >
> 

Mime
View raw message