> 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. >>>>> >>>> >>
