As a fast shoot, I wrapped the log statement right now.
I am still making my mind up if changing the log-level is appropriate,
cause in fact if the variable could not be resolved, there is
something wrong, and that should probably more than a DEBUG message.
Wdyt?
regards,
Martin
On 5/26/05, Broekelmann, Mathias <[EMAIL PROTECTED]> wrote:
> 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:[EMAIL PROTECTED]
> > 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
> > >
> > >
> >
>
