You are viewing a plain text version of this content. The canonical link for it is here.

Posted to log4j-user@logging.apache.org by Marshall Schor <ms...@schor.com> on 2017/02/23 16:39:31 UTC

Using API to set filter on Logger - is ignored by code path Logger.isEnabled() ?

Hi,

I'm writing test cases, using version 2.8 of Log4j.

One test sets a filter on a logger.

Looking (afterwards) at the logger, I see that the logger has a field:

"privateConfig", and that has two fields for configuration info:

- config (set to an instance of XmlConfiguration)
- loggerConfig (has the filter I set on the logger).

The code for isEnabled in Logger (line 238):
 public boolean isEnabled(final Level level, final Marker marker, final Object
message, final Throwable t) {
        return privateConfig.filter(level, marker, message, t);
    }

privateConfig.filter() although it has both a "config" and a "loggerConfig",
only checks the config.

The fact that I successfully used an API to set the loggerConfig with a filter
is ignored.

Should the design for privateConfig.filter() check both configs, or is there
some API call to "merge" the change I did that was recorded in the field
"loggerConfig" into the config stored in the field "config"?

-Marshall Schor

P.S., here's the API call I did to set a filter:

// coreLogger is a cast of a normal logger, to enable the get() method
coreLogger.get().addFilter(myFilter);

// not sure if this is needed, but did it anyways
coreLogger.getContext().updateLoggers(); 



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Using API to set filter on Logger - is ignored by code path Logger.isEnabled() ?

Posted by Matt Sicker <bo...@gmail.com>.

For the CONFIG level, you could match it to the same one in log4j-jul:

https://logging.apache.org/log4j/2.x/log4j-jul/apidocs/src-html/org/apache/logging/log4j/jul/LevelTranslator.html#line.43

On 23 February 2017 at 15:39, Apache <ra...@dslextreme.com> wrote:

> And that issue has now been marked closed. However, there are still a
> couple of synchronized methods in there that are called on every filter
> comparison so we will have to rerun our performance benchmarks to see if it
> made a significant difference.
>
> Ralph
>
> > On Feb 23, 2017, at 2:30 PM, Apache <ra...@dslextreme.com> wrote:
> >
> > Ceki obviously reads this list as he marked SLF4J-240 in progress right
> after I posted the message below. Keep an eye on that for a fix.
> >
> > While your in there Ceki, the contains methods in BasicMarker aren’t
> thread-safe.
> >
> > Ralph
> >
> >> On Feb 23, 2017, at 1:29 PM, Apache <ra...@dslextreme.com> wrote:
> >>
> >> Markers would work but I wouldn’t recommend using them with SLF4J. See
> https://jira.qos.ch/browse/SLF4J-240 <https://jira.qos.ch/browse/SLF4J-240>.
> It has been open for over 5 years so I’m of the impression it will never be
> fixed. http://logging.apache.org/log4j/2.x/performance.html#
> Advanced_Filtering <http://logging.apache.org/log4j/2.x/performance.html#
> Advanced_Filtering> shows that filtering on Markers becomes a huge
> bottleneck in a multithreaded system.
> >>
> >> Ralph
> >>
> >>
> >>> On Feb 23, 2017, at 1:01 PM, Marshall Schor <ms...@schor.com> wrote:
> >>>
> >>>
> >>>
> >>> On 2/23/2017 1:09 PM, Apache wrote:
> >>>> You shouldn’t be trying to modify the logger. You should be trying to
> modify the configuration. Take a look at http://logging.apache.org/
> log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_
> Configuration_after_Initialization <http://logging.apache.org/
> log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_
> Configuration_after_Initialization> <http://logging.apache.org/
> log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_
> Configuration_after_Initialization <http://logging.apache.org/
> log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_
> Configuration_after_Initialization>>. That example creates an appender
> and a logger and adds them. In your case, you would want to find
> loggerConfig associated with your logger by calling config.getLoggerConfig(“loggerName”).
> Then add the filter to that.
> >>>>
> >>>> That said, you should probably explain what you are actually trying
> to do. More often than not, dynamically updating the logging configuration
> is unnecessary as what you really want to do can be achieved other ways.
> >>>
> >>> Thanks.
> >>> What I'm trying to do is to run JUnit testing of an old logging facade
> that I've
> >>> bridged to log4j-2.
> >>>
> >>> In the test, I set a filter, and want to see that it worked.
> >>>
> >>> While I have your attention, I'm bridging from a format that used the
> JUL
> >>> "CONFIG" level, and would like to know how to represent this in a
> "neutral" way
> >>> for modern loggers.  (I'm thinking of SLF4J, Log4J, and LogBack). My
> thought is
> >>> to map CONFIG requests to INFO requests with a "Marker" identifying
> CONFIG.
> >>> Same goes for FINE/FINER - mapping to TRACE, with markers for the two
> >>> alternatives.  To make this work, I'm implementing special "Filters"
> :-).
> >>>
> >>> Is there a better way?  I know you can introduce additional levels in
> Log4j-2,
> >>> but that doesn't seem to be supported in SLF4J and LogBack, and I'm
> looking for
> >>> a more universal approach.
> >>>
> >>> Thanks. -Marshall
> >>>
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Feb 23, 2017, at 9:39 AM, Marshall Schor <ms...@schor.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm writing test cases, using version 2.8 of Log4j.
> >>>>>
> >>>>> One test sets a filter on a logger.
> >>>>>
> >>>>> Looking (afterwards) at the logger, I see that the logger has a
> field:
> >>>>>
> >>>>> "privateConfig", and that has two fields for configuration info:
> >>>>>
> >>>>> - config (set to an instance of XmlConfiguration)
> >>>>> - loggerConfig (has the filter I set on the logger).
> >>>>>
> >>>>> The code for isEnabled in Logger (line 238):
> >>>>> public boolean isEnabled(final Level level, final Marker marker,
> final Object
> >>>>> message, final Throwable t) {
> >>>>>     return privateConfig.filter(level, marker, message, t);
> >>>>> }
> >>>>>
> >>>>> privateConfig.filter() although it has both a "config" and a
> "loggerConfig",
> >>>>> only checks the config.
> >>>>>
> >>>>> The fact that I successfully used an API to set the loggerConfig
> with a filter
> >>>>> is ignored.
> >>>>>
> >>>>> Should the design for privateConfig.filter() check both configs, or
> is there
> >>>>> some API call to "merge" the change I did that was recorded in the
> field
> >>>>> "loggerConfig" into the config stored in the field "config"?
> >>>>>
> >>>>> -Marshall Schor
> >>>>>
> >>>>> P.S., here's the API call I did to set a filter:
> >>>>>
> >>>>> // coreLogger is a cast of a normal logger, to enable the get()
> method
> >>>>> coreLogger.get().addFilter(myFilter);
> >>>>>
> >>>>> // not sure if this is needed, but did it anyways
> >>>>> coreLogger.getContext().updateLoggers();
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> <ma...@logging.apache.org>
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> <ma...@logging.apache.org>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
Matt Sicker <bo...@gmail.com>