rgoers commented on PR #2593: URL: https://github.com/apache/logging-log4j2/pull/2593#issuecomment-2127136770
@ppkarwasz In general I agree with this proposal. If StringArrayThreadContextMap performs the best the I would be in favor of making it the default implementation. I am not sure how you are using the term "garbage free" here. Our documentation talks about "garbage free logging" and that is what the unit tests check for - no garbage being created while logging. Garbage created outside of logging is considered to be OK. By that definition ScopedContext is always garbage free and ThreadContextMap probably is now too, since we no longer copy maps when populating LogEvents. Note that with ScopedContext you should be able to even limit the object creation there by keeping the reference to an Instance. Yes, I understand ThreadContextMap isn't going away. It can't as long as SLF4J is supported. But I really dislike the efforts to "fix" it. I really don't want to support "MDCArmpit" (misspelling is intentional) - https://www.slf4j.org/apidocs-2.1.0/org/slf4j/MDCAmbit.html - as it doesn't really "fix" anything and is just lipstick on a pig. As far as making log4j-api lighter goes.... Using the size of the jar file is meaningless. It could be 1TB but if you are only using 1 class from it that is all that is going to be loaded. I don't believe it is even going to read the whole file from disk. It will just read the directory and directly load the class files it needs as they are referenced. What is far more impactful is the number and size of the classes being loaded. By far the worst culprit is Logger. But we made the conscious decision to explode that interface to improve performance by having so many overloaded methods. Also for comparison: commons-lang: 277K commons-text: 241K guava: 2,982K Toi be honest, this is the first time I have ever actually looked at the size of these jars. I simply don't care since I know there is very little value in it. My point was simply that I am not sure we even need other implementations other than the default. I do agree that the API should contain 1 functional implementation that meets the majority of use cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
