I really don’t know what that code is trying to do. Ralph
> On Jan 15, 2017, at 4:26 PM, Matt Sicker <boa...@gmail.com> wrote: > > I added the dependency exclusion docs to master. > > As for the Spring Boot issue, I made a PR > <https://github.com/spring-projects/spring-boot/pull/7992 > <https://github.com/spring-projects/spring-boot/pull/7992>> to address this. > I consider Configurator to be a more stable internal API than what they were > doing before. > > This does bring me to a separate question: would making a public API to do > this be useful? > > https://github.com/apache/logging-log4j-boot/blob/master/spring/src/main/java/org/apache/logging/log4j/boot/spring/Log4jLoggingSystem.java#L92 > > <https://github.com/apache/logging-log4j-boot/blob/master/spring/src/main/java/org/apache/logging/log4j/boot/spring/Log4jLoggingSystem.java#L92> > > Essentially, an API to get a list of all registered configuration file > formats. As it is now, I need to call some ConfigurationFactory methods > reflectively because they're protected, plus the required use of > PluginManager is not great from an outside-of-log4j-core perspective. It > could be an obscure use case, but some projects that embed a logging library > try to perform some sorts of programmatic configuration like this. > > On 15 January 2017 at 11:26, Matt Sicker <boa...@gmail.com > <mailto:boa...@gmail.com>> wrote: > 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 > <mailto: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 > <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 > <mailto: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-projects/spring-framework/pull/1279 > <https://github.com/spring-projects/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/lagom/pull/270 > <https://github.com/lagom/lagom/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/spring/Log4jLoggingSystem.java#L137 > > <https://github.com/apache/logging-log4j-boot/blob/master/spring/src/main/java/org/apache/logging/log4j/boot/spring/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 > > <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 > <mailto: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 > <mailto: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 >> <mailto:remko.po...@gmail.com>> wrote: >> Another one along similar lines: "10 Log4j2 API features not in SLF4J" >> http://stackoverflow.com/a/41635246/1446916 >> <http://stackoverflow.com/a/41635246/1446916> >> >> :-) >> Remko >> >> Sent from my iPhone >> >> On Jan 13, 2017, at 14:15, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> >>> Jira is down right now, but I have this RFC: >>> https://github.com/apache/logging-log4j-boot >>> <https://github.com/apache/logging-log4j-boot> >>> >>> On 8 January 2017 at 02:16, Remko Popma <remko.po...@gmail.com >>> <mailto: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 >>> <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 >>> <mailto:log4j-dev-unsubscr...@logging.apache.org> >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> <mailto:log4j-dev-h...@logging.apache.org> >>> >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
