JDK-8219914 : Change the environment variable for Java Access Bridge logging to have a directory
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • Submitted: 2019-02-28
  • Updated: 2019-12-08
  • Resolved: 2019-04-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 8 Other
11.0.5-oracleFixed 13 b21Fixed 8u221Fixed openjdk8u232Fixed
Related Reports
CSR :  
JDK-8221680 - Change the environment variable for Java Access Bridge logging to have a directory
Relates :  
JDK-8196681 - Java Access Bridge logging and debug flags dynamically controlled
Description
As the current implementation for Java Access Bridge logging in JDK-8196681 stands, the environment variable can contain either a directory path or a file which is confusing.
To make it simple, it is now being changed to have to point only to a valid directory, and let Java Access Bridge create fixed files.
Comments
Fix request: Backport to 8u is requested because it is a part of 8u221-oracle. No regressions (tested with JAWS screen reader). Backport depends on JDK-8196681, applies cleanly on top of it after paths reshuffling and copyright year correction.
28-10-2019
8u-dev backport depends on JDK-8196681, applies cleanly on top of it after paths reshuffling and copyright year correction. Webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8219914/webrev.00/ Exported changeset with original attribution: http://cr.openjdk.java.net/~akasko/jdk8u/8219914/8219914_8u.changeset CSR for 8u: JDK-8231121
17-09-2019
Thanks! I will ask someone at RH to push it to jdk11u-dev.
12-09-2019
The backport CSR got approved, so this can go into jdk11u-dev.
12-09-2019
Hi Christoph, Thanks for your comments! Sorry for not noticing, that JDK-8215722 has been withdrawn - I was confused by its "Approved" status (and the last comment there). Changed JDK-8230699 to "Withdrawn" and added explanatory comment. Filled JDK-8230698 and changed it to "Proposed". I understand, that approval of the CSR is to be decided by CSR reviewers. Thanks!
07-09-2019
Hi Alex, I just checked the CSR details. The original CSR for JDK-8196681 was withdrawn as the change that had already been pushed wasn't satisfactory to the CSR review. Now this item with its related CSR is obviously used to "repair" it. So, please continue to fill the backport CSR JDK-8230698 that you created and have it reviewed (ideally by the original reviewer). I don't know whether JDK-8230699 will be approved. Thanks Christoph
06-09-2019
Hi Alex, you are obviously right - a CSR for the backports of JDK-8196681 does not exist. As I was the one doing the backport of that to 11u I guess I have simply overlooked the CSR of the original item and/or falsely assumed that the CSR was attached to the Oracle 11.0.5 backport. So, thanks for your offer to retroactively add a CSR to that backport. You should create the CSR from backport bug JDK-8226571 and you can probably link it as well to JDK-8223148. All the rest of the process that you describe here seems right. The CSR process is also used for 8u now. Note, that there isn't a hard requirement to have a fix backported to 11 before it can be accepted for 8. However, it is certainly preferrable to backport items to both update releases in case they apply. Thanks Christoph
05-09-2019
Hi Christoph, Apologies for the incorrect assumption in previous comment that this patch is included into 11.0.5-oracle. I've got this assumption from the RH-internal notes about "feature parity with Oracle Oct 2019 releases" related to this issue, but it seems that in this case it means only 8u231-oracle. I'd still like to confirm the "jdk11u-fix-request" because I am working on backporting AccessBridge changes to 8u. And, as I understand, before being allowed into 8u, it should be pushed into 11u first. On CSR: I was following the wiki page you linked, and generally found it very helpful, but the part about the CSR is a bit confusing: - this issue (JDK-8219914) depends on the issue you mentioned (JDK-8196681) - both issues have CSR-issues linked to them (JDK-8215722, JDK-8221680) - 11u backport for the first issue (JDK-8226571) is not marked with "11-pool" and doesn't have a separate "CSR for 11u" linked to it I am willing to proceed with CSR process for both issues, and will appreciate any guidance on that. If I understand the CSR process for jdk-updates correctly, I need to do the following: 1. retroactively file a 11u CSR for JDK-8196681 and get it approved 2. file a 11u CSR for JDK-8219914 (this issue) and get it approved (at this point "jdk11u-fix-request" can also be approved) 3. backport both issues (and probably one of the dependent AccessBridge changes) to 8u 4. get backported issues (won't apply cleanly) reviewed 5. file a "unified" 8u CSR for both issues and get it approved 6. add a "jdk8u-fix-request" for 8u and get it approved Thanks!
04-09-2019
Hi Alex, as per the backports linked with this issue, it seems not to be part of Oracle's 11.0.5 (unless they've hidden the backport bug). Furthermore, it has an attached CSR. So you'll also have to file a CSR for JDK11 updates and have it reviewed. Once this is done, the patch can probably be approved, though. Best regards Christoph In case you have questions regarding the process (e.g. how to create the CSR), please refer to this URL: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
04-09-2019
Fix request: Backport requested because it's part of Oracle 11.0.5. Patch applies cleanly. No regressions (tested with JAWS screen reader).
03-09-2019
[~psrivastava] [~kaddepalli] [~pbansal] what is a current status of this bug fix?
24-04-2019