Restore compatibility of Log4j API #2203
Conversation
|
This looks good to me. |
| * Kept for binary compatibility. | ||
| */ | ||
| @Deprecated(forRemoval = true) | ||
| public static final String FACTORY_PROPERTY_NAME = "log4j2.loggerContextFactory"; |
There was a problem hiding this comment.
I suppose we can keep these strings, but by 3.0.0, they'll be functionally useless due to #1977
There was a problem hiding this comment.
There is actually a compatibility mechanism developed by Ralph (cf. log4j2.propertyMapping.json) that allows log4j2.loggerContextFactory to still work.
I had doubts about reintroducing this: it is a compile-time constant, so it will be inlined in all binary artifacts. As far as source compatibility is concerned, I think we could remove it. What do you think?
There was a problem hiding this comment.
What I mean is that specifying custom classes to use for things will likely use some sort of code-based way of doing so rather than a system property.
|
I have removed the two deprecated |
This restores backward compatibility of `log4j-api` from a user's perspective and adds comments to classes that should not have breaking changes. I have checked all the types in `org.apache.logging.log4j` and those reachable through inheritance or signature of public methods in other packages: ``` org.apache.logging.log4j.message.EntryMessage org.apache.logging.log4j.message.ExitMessage org.apache.logging.log4j.message.FlowMessage org.apache.logging.log4j.message.FlowMessageFactory org.apache.logging.log4j.message.Message org.apache.logging.log4j.message.MessageFactory org.apache.logging.log4j.spi.LoggerContext org.apache.logging.log4j.spi.ExtendedLogger org.apache.logging.log4j.spi.LoggerContextFactory org.apache.logging.log4j.spi.LoggerRegistry org.apache.logging.log4j.spi.StandardLevel org.apache.logging.log4j.spi.ReadOnlyThreadContextMap org.apache.logging.log4j.util.BiConsumer org.apache.logging.log4j.util.ReadOnlyStringMap org.apache.logging.log4j.util.StringMap org.apache.logging.log4j.util.StringBuilderFormattable org.apache.logging.log4j.util.Supplier org.apache.logging.log4j.util.TriConsumer ``` The only breaking changes I found are `Logger#entry/exit` and in `MarkerFactory`. I believe we should restore them and have a 100% binary compatibility with `2.x`, rather then breaking BC for almost nothing.
The two `MarkerFactory#getMarker` methods were marked as deprecated **before** the `2.0` release, therefore I find it safe to actually remove them.
3 participants
This restores backward compatibility of
log4j-apifrom a user's perspective and adds comments to classes that should not have breaking changes.I have checked all the types in
org.apache.logging.log4jand those reachable through inheritance or signature of public methods in other packages:The only breaking changes I found are
Logger#entry/exitand in. I believe we should restore them and have a 100% binary compatibility withMarkerFactory2.x, rather then breaking BC for almost nothing.This PR also adds
forRemovalto all the classes that where deprecated in2.x, but not removed in3.x.Part of #2163