vlsi commented on issue #5937: URL: https://github.com/apache/jmeter/issues/5937#issuecomment-2271160800
> I agree with you, but how do you suggest to do it? a. Avoid printing the warnings b. If you absolutely want printing a warning, then consider phrasing it in such a way the users could make a reasonable action. For instance, consider what OpenJDK does with "illegal reflective access" ``` WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/C:/.../.m2/repository/com/google/inject/guice/4.2.2/guice-4.2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release ``` They have "Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1". Of course, it is not as good as JMeter build-time warning, but having something like "please consider reporting it to the maintainers of org.apache.jmeter.gui.logging.GuiLogEventAppender" would be better than the current log4j message. > so users can always upgrade to the last version of the supported major versions (2.x and soon 3.x) without breaking changes. When patching a security issue, everybody wants just the security fix, and they do not want "an extra year worth of features and bugfixes". There are cases when upgrading **minor** versions is prohibited. For instance, Spring Boot policy is to keep using the same **minor** versions for the third-party dependencies: https://github.com/pgjdbc/pgjdbc/issues/2599#issuecomment-1222423561 That is one of the reasons pgjdbc/pgjdbc patches security issues in **all** minor versions by default (see https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-24rp-q3w6-vc56), and pgjdbc team can roll a security fix to literally **any** version on demand (see https://github.com/pgjdbc/pgjdbc/security/policy). Once again: I'm not against upgrading to a recent version from time to time. However I would like to have a version that has just a necessary changes to fix the CVE when in a hurry of patching a CVE. I do not like the way log4j2 team handles CVEs by forcing everybody upgrading to the latest minor. >For JPMS reasons you should probably move the GuiLogEventAppender out of [ApacheJMeter_core](https://mvnrepository.com/artifact/org.apache.jmeter/ApacheJMeter_core/5.6.3) into a separate artifact That is so true -- 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...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
