rschmitt commented on PR #3852: URL: https://github.com/apache/logging-log4j2/pull/3852#issuecomment-3127967492
> how feasible is it for you to fix code paths accessing deprecated Log4j APIs? @vy I already have a variety of issues associated with 2.25 that I am working on fixing. For example, the JSpecify annotations added in commits like a1dfa853c96604ded1f253da2ec25f8f2f95ef25 are breaking JDK8 builds that are using Mockito to mock APIs with those annotations, because they don't have those annotations on their test classpath. (This appears to be a bug in core reflection. It works fine on JDK17.) Other builds are failing due to the combination of `-Werror` and `-Xlint:classfile`, due to those same annotations: if they're not on the compilation classpath, a linter warning gets emitted due to `-Xlint:classfile`, which gets upgraded to a compilation error by `-Werror`. One library was using `ThrowableProxy`, and its tests started failing because `setThrownProxy` was changed to a no-op; I had to patch it to use `Throwable`/`setThrown`. I haven't submitted issues or bug reports for any of these things, because they're not obviously regressions in Log4j itself, and I have to either fix the packages that can't upgrade or patch Log4j itself to work around the issue. This issue OTOH is clearly a regression, because the method doesn't do what the Javadoc says it should, and there's some sort of validation logic in 2.25 that is surfacing the problem. Since this _is_ a bug, I'd rather fix it upstream than change all the consumers to use non-deprecated code paths, since that would just take time away from the issues I've listed in the previous paragraph, which I'm still working on. -- 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
