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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] <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)" <[email protected] >> <mailto:[email protected]> <javascript:;> >> <mailto:[email protected] <mailto:[email protected]> <javascript:;>>> >> >>> *Date:* April 23, 2016 at 4:13:12 AM MST >> >>> *To:* [email protected] >> <mailto:[email protected]> <javascript:;> >> <mailto:[email protected] >> <mailto:[email protected]> <javascript:;>> >> >>> *Subject:* *[jira] [Closed] (LOG4J2-1375) Update SLF4J from >> 1.7.13 to >> >>> 1.7.21* >> >>> *Reply-To:* "Log4J Developers List" >> <[email protected] <mailto:[email protected]> >> <javascript:;> >> >>> <mailto:[email protected] >> <mailto:[email protected]> <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: >> [email protected] >> <mailto:[email protected]> <javascript:;> >> >>> <mailto:[email protected] >> <mailto:[email protected]> <javascript:;>> >> >>> For additional commands, e-mail: >> [email protected] >> <mailto:[email protected]> <javascript:;> >> >>> <mailto:[email protected] >> <mailto:[email protected]> <javascript:;>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> <javascript:;> >> > For additional commands, e-mail: >> [email protected] >> <mailto:[email protected]> <javascript:;> >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
