huhmare commented on PR #2148: URL: https://github.com/apache/cxf/pull/2148#issuecomment-2476001329
Thank you. The CXF tests are run with "--add-opens java.base/java.lang=ALL-UNNAMED" by default. The test ClientServerExceptionTest.exceptionCustomExceptionMessageIsPreserved fails without it. The test is bit misleading, as the CXF-9076 is about using jdk17+ without add-opens. As I understand, using this PR with JDK17+ without add-opens: - java.lang.*Exceptions will have detailMessages, if it has a constructor(String, Throwable). - Any other (Sub)Exception will not have it, so that we can have member variables in subclasses. Difference to before CXF-9076 is that we will have detailMessage in some java.lang.*Exceptions. The necessary constructor is found in 11 / 29 Exceptions (openJDK17+35). For example SecurityException has it, and IllegalAccessException does not. There are 3 exceptions (ClassNotFoundException, EnumConstantNotPresentException, TypeNotPresentException) in java.lang that have their own member variables. Only TypeNotPresent will be affected by these CXF-9076 changes. Not a big problem. All in all, this and the previous PR are small step to right direction, but are not a complete solution to the general problem. In the code base I am working with, we still probably have to use either: * add-opens OR * rewrite the code to not rely on detailMessage OR * rewrite subExceptions to hide Throwable.detailMessage with a our own detailMessage and get/set methods in the subclass. These PRs might help us in case we have a java.lang.*Exception thrown out of the SOAP-interface. But it will not cover for example java.sql.SQLException. Unfortunately I do not have a suggestion for a correct way of doing this. Dynamic Proxy works only with interfaces(?), so a way to create instance with getMessage returning correct value would propably need bytecode manipulation stuff. -- 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: dev-unsubscr...@cxf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
