[
https://issues.apache.org/jira/browse/LOG4J2-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381377#comment-14381377
]
Daniel Norberg commented on LOG4J2-978:
---------------------------------------
No, we have hundreds of applications, the source code of which lives in
hundreds of git repositories, developed/deployed/operated by hundreds of
application engineers. The machines we have are in the thousands. Deploying
files onto them is not really a big problem for us per se, although migrating
from our current logging configuration setup to deploying application specific
logging configuration files to all hosts is a non-insignificant task.
Not saying that either programmatic configuration or configuration files are
generally better. It all boils down to specific use cases and circumstances.
Please bear with me.
To provide some more context; We give our application engineers ownership over
a lot of the stack. In the context of logging, the infrastructure/operations
team ownership essentially ends at the syslog daemons running on all hosts. The
logging stack above that, i.e. whatever needs to happen for applications to
send logs to syslog, is owned by the application engineers. We provide
libraries and frameworks that the application engineers can use to make their
life easier wrt logging and other aspects of their applications. As such, we
have a bit of a bazaar model. We have no team that would go through all our
applications and swap out e.g. logback for log4j2 and make sure that the
correct log files are in place. We do have engineers (e.g. me) that can make
changes to the shared libraries and frameworks, that the application engineers
can then upgrade to bring in good stuff like log4j2 instead of logback. My
motivation for e.g. migrating from logback to log4j2 is that I see that log4j2
has the potential to be more robust and performant, lessening the amount of
support I need to provide to application engineers using my libraries.
In our case, a migration path from logback to log4j2 that involves our
application engineers learning a new logging configuration file format and
adding configuration files to their applications is unlikely to happen. If the
migration path can simply be pulling in a newer version of our frameworks, then
the migration will happen, potentially without the application engineer even
noticing. Many of our application engineers are today likely blissfully unaware
that they are currently using logback.
To get back to the topic of configuration files vs programmatic configuration,
I believe there are valid use cases for robust programmatic configuration
facilities alongside the use of configuration files. However, if I could get
away with simply e.g. bundling a few log4j2 configuration files in my library
instead of doing programmatic configuration, that would be good enough for me.
I'll look into if that's feasible.
Thanks for your help, and keep up the good log4j2 work!
> 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]
