logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Slf4j & (legacy?) best practices
Date Sun, 15 Jan 2017 23:26:36 GMT
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 <boards@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.popma@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 <boards@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/
>>> Log4jLoggingSystem.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.popma@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 <boards@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.popma@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 <boards@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.popma@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com>
>>>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message