The change, if I remember right, was the need to inject the current LoggerContext. I don't remember the scenario that caused it, but really, Spring Boot was using an internal configuration API instead of using LogManager (the stable, public API) like I did in my version. If we added a reconfigure() method to the public API of LoggerContext, then I'd be able to implement most of the LoggingSystem class using only public APIs.
The other two internal APIs I needed to use are finding out which configuration file formats are supported (though I don't fully understand the scope of that method I implemented; it might not be super useful) and the ability to set a log level on a logger by getting its LoggerConfig (though I'm still confused if that's the right way to do it or if I should use the core.Logger.setLevel() method that claims it's for unit tests). I'll add some docs about dependency exclusion since I've used that feature a bunch already at work. On 15 January 2017 at 02:14, Remko Popma <remko.po...@gmail.com> wrote: > That is bad news... So our changes broke Spring boot's log4j2 logging? > They only just removed Log4j 1 support... We really should be more careful > about not breaking backwards compatibility. > That said, just from looking at the code I can't see why their code should > not work. What change broke it? > > Back to the topic of the dependency issues some people appear to have, I > just found this link https://www.slf4j.org/faq.html#excludingJCL, > wondering if we can add something similar to our documentation. I think > there is a need but I don't have the knowledge to do the write-up. > > > On Sun, Jan 15, 2017 at 3:15 PM, Matt Sicker <boa...@gmail.com> wrote: > >> The only dependencies I ever end up having to exclude are log4j 1.2 and >> logback, but that's normally from internal projects not having a consistent >> logging configuration yet. >> >> I've made a PR to spring to update their docs to recommend log4j 2 >> instead of 1.x: <https://github.com/spring-pro >> jects/spring-framework/pull/1279> >> >> As I come across projects that I use at work, I've been making PRs to add >> support or docs about log4j. See Lagom: <https://github.com/lagom/lago >> m/pull/270>. >> >> Really, it might be helpful to just get log4j 2 mentioned in more >> framework docs. A lot of projects are still recommending log4j 1.x! >> >> As for using log4j-boot-spring, it'd be a replacement for spring-boot's >> own logger modules which use logback by default (and their log4j2 version >> doesn't work with 2.7+ because they coded it to use internal >> ConfigurationFactory methods which changed in 2.7). Compare: >> >> https://github.com/apache/logging-log4j-boot/blob/master/ >> spring/src/main/java/org/apache/logging/log4j/boot/spri >> ng/Log4jLoggingSystem.java#L137 >> >> https://github.com/spring-projects/spring-boot/blob/master/ >> spring-boot/src/main/java/org/springframework/boot/logging/ >> log4j2/Log4J2LoggingSystem.java#L170 >> >> On 14 January 2017 at 23:37, Remko Popma <remko.po...@gmail.com> wrote: >> >>> One complaint I keep seeing is that libraries coding to the Log4j2 API >>> would somehow result in problems with dependency configuration. >>> >>> I have been fairly isolated from such kind of problems so I don't >>> understand when this could happen and what might cause it. >>> >>> The only hint I got was a brief reply on twitter: >>> "Problems I've had result in lots of slf4j exclusions in my maven deps. >>> IIRC the biggest offender was Jersey, but I don't have access to the >>> project anymore." >>> >>> When/why would it be necessary to have lots of slf4j exclusions in the >>> maven dependencies? >>> >>> Is there something we can do (docs or otherwise) to help with this? (Not >>> sure if/how the log4j-boot project would help with such issues, I never >>> used Spring boot.) >>> >>> Remko >>> >>> Sent from my iPhone >>> >>> On Jan 15, 2017, at 13:59, Matt Sicker <boa...@gmail.com> wrote: >>> >>> I've been seeing your posts on /r/java which could help spark some >>> discussions. :) >>> >>> On 14 January 2017 at 22:57, Remko Popma <remko.po...@gmail.com> wrote: >>> >>>> Another one along similar lines: "10 Log4j2 API features not in SLF4J" >>>> http://stackoverflow.com/a/41635246/1446916 >>>> >>>> :-) >>>> Remko >>>> >>>> Sent from my iPhone >>>> >>>> On Jan 13, 2017, at 14:15, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>> Jira is down right now, but I have this RFC: https://github.com/apache >>>> /logging-log4j-boot >>>> >>>> On 8 January 2017 at 02:16, Remko Popma <remko.po...@gmail.com> wrote: >>>> >>>>> Speaking of slf4j, I would like to evangelize that applications should >>>>> code to the Log4j2 API as a best practice. See also >>>>> http://stackoverflow.com/a/41500347/1446916 >>>>> >>>>> I'm thinking to do a blog post along these lines. >>>>> >>>>> Thoughts? Maybe also something to emphasize on the site? >>>>> >>>>> Sent from my iPhone >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> > > -- Matt Sicker <boa...@gmail.com>
