[
https://issues.apache.org/jira/browse/LOG4J2-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368700#comment-14368700
]
Daniel Norberg commented on LOG4J2-978:
---------------------------------------
Remko, let me try to explain our setup a little more in detail.
We have a couple of hundred different backend services. Most of them use our
[logging setup library|https://github.com/spotify/logging-java] to set up
logging in a way that fits our logging infrastructure. This typically takes the
form of a single call like {{LoggingConfigurator.configureDefaults();}}.
Logging setup is completely programmatic and there's no configuration file
involved. Among other things this has allowed us to easily migrate from log4j
1.x to logback a few years back without engineers having to change any
configuration files.
Likewise this would allow us to migrate from logback to log4j2. However, the
public classes and interfaces that need to be instantiated/called in order to
perform programmatic setup of log4j2 live in {{log4j-core}} and are, as you
explained, evolving and might have breaking changes in minor versions. So I was
wondering if there was a more future-proof mechanism for programmatically
setting up log4j2. I assumed that even though {{log4j-core}} might have
breaking changes, configuration file format changes would be more rare and as
such generating configuration files would be a heavy handed way of avoiding
calling into {{log4j-core}} and the associated impact of breaking changes in
{{log4j-core}}. Builders as mentioned by Gary would seem to be a more palatable
solution.
Does that make sense?
> log4j2 2.2 made breaking changes to public classes
> --------------------------------------------------
>
> Key: LOG4J2-978
> URL: https://issues.apache.org/jira/browse/LOG4J2-978
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.2
> Reporter: Daniel Norberg
>
> The log4j2 2.2 release contained breaking changes to public classes, breaking
> direct uses and extenders of log4j2 interfaces.
> E.g.
> https://github.com/apache/logging-log4j2/commit/3cdbbeddf19137d20fa6527d6620e88afcecb7f9
> Here is an example of the impact of this breaking change:
> https://github.com/spotify/logging-java/commit/3d2ca1c31a8ca3eabe1db378e2df48e0757e80e7
> Does log4j2 aim to follow semantic versioning? I am currently looking into
> the feasibility of taking log4j2 into use instead of logback, but this will
> not be possible if log4j2 will be having further breaking changes in minor
> releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
