Hi, Petr.
The fix looks good to me too.
On 5/23/14 1:20 AM, Anthony Petrov wrote:
Thanks, Petr. The fix for the stack trace issue still looks fine to me.
--
best regards,
Anthony
On 5/23/2014 1:19 AM, Petr Pchelko wrote:
Closing this bug as Cannot Reproduce sounds like a good idea to me
because we'll be able to re-open it if someone reproduces the issue
again in the future.
I have filed https://bugs.openjdk.java.net/browse/JDK-8043807 for
incorrect stack trace issue. This fix will go under that bug ID.
The original bug will be closed a cannot reproduce.
With best regards. Petr.
On May 23, 2014, at 1:15 AM, Anthony Petrov
<[email protected]> wrote:
Closing this bug as Cannot Reproduce sounds like a good idea to me
because we'll be able to re-open it if someone reproduces the issue
again in the future.
--
best regards,
Anthony
On 5/23/2014 1:01 AM, Petr Pchelko wrote:
If I disable clipboard sharing in RDP it works without problems.
If I copy something into the clipboard after establishing the
connection but before invoking the code it works without problems.
Petr, do you have any comments about this? Perhaps we should fix
the stack trace origin issue under a separate bug id, and leave
this bug open to address the original clipboard-shared-over-RDP
issue?
I couldn’t reproduce this although I’ve tried really hard. I can
fix stack trace origin under separate bugId, but this one I’m going
close as cannot reproduce anyway.
More that that, looking at the code which throws the IOException I
would say that this is more likely an RDP-client bug, not our bug.
All we do here is call winapi function ::EnumClipboardFormats to
get all available format and then call ::GetClipboardData for each
format from that list. No place for a bug left here..
With best regards. Petr.
On May 23, 2014, at 12:52 AM, Anthony Petrov
<[email protected]> wrote:
Interesting. I took a closer look at the bug report and found this:
If I disable clipboard sharing in RDP it works without problems.
If I copy something into the clipboard after establishing the
connection but before invoking the code it works without problems.
Petr, do you have any comments about this? Perhaps we should fix
the stack trace origin issue under a separate bug id, and leave
this bug open to address the original clipboard-shared-over-RDP
issue?
--
best regards,
Anthony
On 5/22/2014 11:44 PM, Petr Pchelko wrote:
Hello, Sergey.
Submitter complains about IOException itself, not about
incorrect stack trace.
The IOException is fine.
It’s thrown from a different method (not as the stacktace states)
and it’s OK by documentation.
Just the stack trace is “wrong”.
We can’t fix the IOException, because the clipboard was not ready
and we can’t do anything about it.
With best regards. Petr.
On May 22, 2014, at 10:44 PM, Sergey Bylokhov
<[email protected]> wrote:
Hi, Petr.
Submitter complains about IOException itself, not about
incorrect stack trace.
On 5/22/14 1:39 PM, Anthony Petrov wrote:
Looks fine.
--
best regards,
Anthony
On 5/21/2014 4:27 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fox for the issue:
https://bugs.openjdk.java.net/browse/JDK-8043513
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8043513/webrev/
The problem:
When we fetch all contents from the clipboard we catch
IOException and store it for later.
In case we would then need the data which caused the exception
the cached exception would be rethrown.
But the stack trace shows where the exception was created, not
thrown. Wrapping it helps to
eliminate the misunderstanding.
With best regards. Petr.
--
Best regards, Sergey.
--
Best regards, Sergey.
