I believe it's used by Spring Boot to find a log4j2-spring.ext file based on which file formats are supported by the underlying system. For example, the logback integration looks for logback-spring.xml and logback-spring.groovy files. I've never used that feature myself as I just use the normal file name, but it must be supported by Spring for a reason.
On 15 January 2017 at 18:27, Apache <ralph.go...@dslextreme.com> wrote: > 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> 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 > > 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> 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> 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/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/spr >>>> ing/src/main/java/org/apache/logging/log4j/boot/spring/Log4j >>>> LoggingSystem.java#L137 >>>> >>>> https://github.com/spring-projects/spring-boot/blob/master/s >>>> pring-boot/src/main/java/org/springframework/boot/logging/lo >>>> g4j2/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> >> > > > > -- > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
