logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-978) log4j2 2.2 made breaking changes to public classes
Date Mon, 18 May 2015 23:54:59 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549528#comment-14549528
] 

Ralph Goers edited comment on LOG4J2-978 at 5/18/15 11:54 PM:
--------------------------------------------------------------

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 would think carefully 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.

As for the Charsets class, it was removed because there was a question regarding its provenance.
Furthermore, with the next release of Log4j that class would be completely unnecessary as
version 2.4 will require Java 7.




was (Author: ralph.goers@dslextreme.com):
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message