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.
