[
https://issues.apache.org/jira/browse/LOG4J2-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549528#comment-14549528
]
Ralph Goers commented on LOG4J2-978:
------------------------------------
1. I do not have a problem with the enhancement to add the requested features
to the SyslogAppender, although it should be pointed out that doing that would
be a "breaking change" by the definition of this Jira issue.
2. I agree with Gary that moving to RFC 5424 is a better way to go.
It may not be apparent with Log4j 1 since it hasn't really been updated in
years, but these kinds of "breaking changes" were quite common, but it was not
nearly so obvious what was guaranteed and what was not. We specifically broke
Log4j into an API and an implementation to make it obvious what the guarantees
are. That said, we woudl think carefually about changing even some of the
parts of log4j-core, such as some of the base interfaces. But we have to have
some latitude to be able to make enhancements or fix bugs so we cannot possibly
lock down everything. It is quite likely that specific Appender and Layout
implementations may change from one release to the next, but almost always
maintaining backward compatibility for those using the standard XML, JSON or
YAML configurations.
> 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]