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

Gary Gregory commented on LOG4J2-978:
-------------------------------------

[~danielnorberg]: Thank you for explaining your use case. It helps.

Well, let's see, where are we? 
- The log4j-api module is set in stone for BC stone for 2.x. But it does not 
have APIs for programmatic configuration, it's not its job.
- The log4j-core module contains the config API but it is not set in stone for 
BC but we do try not make call sites' lives more difficult. We make changes 
when we have to.
- The configuration file formats (XML, JSON, YAML) should be compatible within 
2.x. That means that changes in the core should not break existing config 
files. This has been true in all 2.x releases.
- The core does contain some components which configurable the Builder pattern. 
That should make such components less brittle.

So today, the safest config method is the config file. The API is more direct 
obviously but might be tweaked from time to time.

All that said, how can we help you succeed with Log4j? Specifically with the 
upcoming 2.3 release for example.

Thank you,
Gary

> 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]

Reply via email to