logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [jira] [Created] (LOG4J2-1375) Update SLF4J from 1.7.13 to 1.7.21
Date Sat, 23 Apr 2016 17:00:10 GMT
I suppose that depends on the definition of “event loss”.  You can’t log without a LoggerContext
and the LoggerContext is initialized with a default configuration, which means errors will
be logged to the console. We could create a default configuration that buffers the events
and logs then again when stop is called.

Ralph

> On Apr 23, 2016, at 7:18 AM, Ceki Gulcu <ceki@qos.ch> wrote:
> 
> You are welcome.
> 
> In the principle, the  event loss issue (fixed by event replay post-initialization) depends
on the time it takes for the underlying implementation to initialize. Unless you can guarantee
that log4j2 initializes instantly**, during SLF4J initialization event loss will occur with
log4j2 as well. Note the event loss issue is limited to applications using slf4j which are
multi-threaded early on.
> 
> > Would you mind sharing which applications perform reflection on
> > the org.slf4j.Logger implementation (and why)?
> 
> The typical example is Spring which may do reflection on logger instances. If the org.slg4j.Logger
implementation offers the log(org.slf4j.event.LoggingEvent) method, then the org.slf4j.event.LoggingEvent
interface must exist on the class path. Otherwise, the Spring initialization will fail. The
org.slf4j.event.LoggingEvent interface was introduced in slf4j-api version 1.7.15. It follows
that if you decide to make use of the slf4j replay feature, then log42 will de facto depend
on slf4j version 1.7.15 both at compile and runtime.
> 
> --
> Ceki
> 
> **I am presuming here that log4j2 initializes when it creates and returns its first Logger.
> 
> On 4/23/2016 15:54, Remko Popma wrote:
>> ...and thank you for the info, Ceki, that is certainly helpful!
>> 
>> Remko
>> 
>> On Saturday, 23 April 2016, Remko Popma <remko.popma@gmail.com <mailto:remko.popma@gmail.com>
>> <mailto:remko.popma@gmail.com <mailto:remko.popma@gmail.com>>> wrote:
>> 
>>    Question: does the replay support solve a problem in SLF4J or in
>>    Logback initialization?
>> 
>>    If the latter, then perhaps there's no need to implement the new
>>    method since log4j-slf4j-impl binds to log4j2 anyway, no?
>> 
>>    Remko
>> 
>>    Sent from my iPhone
>> 
>>     > On 2016/04/23, at 22:12, Ceki Gulcu <ceki@qos.ch <javascript:;>>
>>    wrote:
>>     >
>>     > Hello,
>>     >
>>     > For your information, slf4j-api version 1.7.21 will work with
>>    current versions of log4j2 just fine albeit without replay support.
>>    For replay support, log4j2's implementation of org.slf4j.Logger
>>    interface needs to have a method with the signature
>>    log(org.slf4j.event.LoggingEvent) in which case events generated
>>    during SLF4J initialization will be replayed. Note that if log4j2's
>>    Logger implementation chooses to implement the aforementioned log
>>    method, log42 will de facto depend on SLF4J version 1.7.15 and later
>>    both at compile and *runtime*.
>>     >
>>     > The runtime dependency might seem surprising but some
>>    applications perform reflection on the org.slf4j.Logger
>>    implementation which will fail without slf4j-api 1.7.15 or later
>>    being present on the classpath.
>>     >
>>     > I hope this helps,
>>     >
>>     > --
>>     > Ceki
>>     >
>>     >> On 4/23/2016 14:47, Ralph Goers wrote:
>>     >> We are not fully compatible with this version of SLF4J.  It had some
>>     >> initialization race conditions so Substitute Loggers were invented.
>>     >> Anyway, there is a new interface we need to implement.
>>     >>
>>     >> Ralph
>>     >>
>>     >> Begin forwarded message:
>>     >>
>>     >>> *From:* "Remko Popma (JIRA)" <jira@apache.org <mailto:jira@apache.org>
<javascript:;>
>>    <mailto:jira@apache.org <mailto:jira@apache.org> <javascript:;>>>
>>     >>> *Date:* April 23, 2016 at 4:13:12 AM MST
>>     >>> *To:* log4j-dev@logging.apache.org <mailto:log4j-dev@logging.apache.org>
<javascript:;>
>>    <mailto:log4j-dev@logging.apache.org <mailto:log4j-dev@logging.apache.org>
<javascript:;>>
>>     >>> *Subject:* *[jira] [Closed] (LOG4J2-1375) Update SLF4J from
>>    1.7.13 to
>>     >>> 1.7.21*
>>     >>> *Reply-To:* "Log4J Developers List"
>>    <log4j-dev@logging.apache.org <mailto:log4j-dev@logging.apache.org> <javascript:;>
>>     >>> <mailto:log4j-dev@logging.apache.org <mailto:log4j-dev@logging.apache.org>
<javascript:;>>>
>>     >>>
>>     >>>
>>     >>>    [
>>     >>>
>>    https://issues.apache.org/jira/browse/LOG4J2-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
<https://issues.apache.org/jira/browse/LOG4J2-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
>>     >>> ]
>>     >>>
>>     >>> Remko Popma closed LOG4J2-1375.
>>     >>> -------------------------------
>>     >>>   Resolution: Fixed
>>     >>>
>>     >>>> Update SLF4J from 1.7.13 to 1.7.21
>>     >>>> ----------------------------------
>>     >>>>
>>     >>>>               Key: LOG4J2-1375
>>     >>>>               URL:
>>    https://issues.apache.org/jira/browse/LOG4J2-1375 <https://issues.apache.org/jira/browse/LOG4J2-1375>
>>     >>>>           Project: Log4j 2
>>     >>>>        Issue Type: Improvement
>>     >>>>        Components: SLF4J Bridge
>>     >>>>  Affects Versions: 2.5
>>     >>>>          Reporter: Remko Popma
>>     >>>>          Assignee: Remko Popma
>>     >>>>           Fix For: 2.6
>>     >>>>
>>     >>>>
>>     >>>> Update SLF4J from 1.7.13 to 1.7.21
>>     >>>
>>     >>>
>>     >>>
>>     >>> --
>>     >>> This message was sent by Atlassian JIRA
>>     >>> (v6.3.4#6332)
>>     >>>
>>     >>>
>>    ---------------------------------------------------------------------
>>     >>> To unsubscribe, e-mail:
>>    log4j-dev-unsubscribe@logging.apache.org <mailto:log4j-dev-unsubscribe@logging.apache.org>
<javascript:;>
>>     >>> <mailto:log4j-dev-unsubscribe@logging.apache.org <mailto:log4j-dev-unsubscribe@logging.apache.org>
<javascript:;>>
>>     >>> For additional commands, e-mail:
>>    log4j-dev-help@logging.apache.org <mailto:log4j-dev-help@logging.apache.org>
<javascript:;>
>>     >>> <mailto:log4j-dev-help@logging.apache.org <mailto:log4j-dev-help@logging.apache.org>
<javascript:;>>
>>     >
>>     > ---------------------------------------------------------------------
>>     > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <mailto:log4j-dev-unsubscribe@logging.apache.org>
>>    <javascript:;>
>>     > For additional commands, e-mail:
>>    log4j-dev-help@logging.apache.org <mailto:log4j-dev-help@logging.apache.org>
<javascript:;>
>>     >
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <mailto:log4j-dev-unsubscribe@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.org <mailto:log4j-dev-help@logging.apache.org>

Mime
View raw message