Community
Participate
Working Groups
Drag and Drop a filter just above itself and you will get the error: File kevin.Local.interface org.eclipse.rse.services.files.IFileService.kevin.kevin:local.files.a not found on host Local Same thing happens when dragging and dropping the filter to a folder, remote scratchpad, etc. Log shows: !ENTRY org.eclipse.rse.ui 4 0 2007-05-17 20:08:08.163 !MESSAGE RSEG1106E: SUB#0:kevin.Local.interface org.eclipse.rse.services.files.IFileService.kevin.kevin:local.files.a !ENTRY org.eclipse.rse.ui 4 0 2007-05-17 20:08:08.163 !MESSAGE RSEG1106E: SUB#1:Local -----------Enter bugs above this line----------- TM 2.0M7 Testing installation : eclipse-SDK-3.3M7 RSE install : I20070517-0600 java.runtime : Sun 1.5.0_06-b05 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------
There seems to be a problem with the filter naming here such that we're not able to match a filter with the name we have.
I've tried to implement some code in the getFilterReferenceWithAbsoluteName(String key) method to take the proper string to work with prior to processing. My solution works, Although an issue arises if the Filter were to have any "." or ":" characters, which is currently being allowed to the user. Basic idea below String key = kevin.Local.interface org.eclipse.rse.services.files.IFileService.kevin.kevin:local.files.a and after executing some string methods we have something easier to work with in order to return the proper information, initial code was attempting to get the below information from the string above and is failing: kevin.kevin:local.files.a SystemFilterPoolManager : kevin filterPoolName : kevin:local.files filterName : a
Created attachment 70525 [details] solution for getFilterReferenceWithAbsoluteName method to return proper filter reference I have come with a workaround with the issue I stated above. The correct filter reference is now being returned by the getFilterReferenceWithAbsoluteName method. The filters can be now moved to the scratchpad. The patch has resolved the defect. Although, there is another issue that is present (NPE) that only occurs sometimes when the filter is moved above or below itself. This NPE is occuring in the SystemDNDTransferRunnable.java class and I will take a look to see if I can resolve the issue now. Stack from log: !ENTRY org.eclipse.core.jobs 4 2 2007-06-07 11:59:55.369 !MESSAGE An internal error occurred during: "Transfer Operation". !STACK 0 java.lang.NullPointerException at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.transferRSEResources(SystemDNDTransferRunnable.java:247) at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.runInWorkspace(SystemDNDTransferRunnable.java:575) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
I, Rupen Mardirossian, declare that I developed attached code above from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
Created attachment 70572 [details] Removes NPE explained above when attempting to dnd a filter. The problem was occuring when trying to drag to 'DRIVES' filter on the local giving a NPE becuse the target was returning as null. Path being " ". Just put in a check to see if the target is null and return false. This fixed the issue. I, Rupen Mardirossian, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
The second patch looks good. The thing I'm worried about with the first patch is that it assumes a naming convention based on the signature of the service interface and this is likely to change. We're going to have think about this a bit more.
I'd like to apply the second patch for RC3 but defer the first issue for later. Martin, what do you think?
Martin is not around. Dave I want to know whether you think we should apply the second patch for this or not for RC3.
Moving this to 2.0.1 for now.
I don't think this is high enough priority to put this patch in so I'm rejecting it. Please move it to 2.0.1.
I've applied the second patch. For the first issue, I'm going to defer until later.
Kevin should we assign a different target milestone for this? What's the current status of this?
It's my understanding that nobody has worked on this. Correct Dave?
(In reply to comment #13) > It's my understanding that nobody has worked on this. Correct Dave? No, as far as I know, nobody has worked on this.
Closing this to clean up our IP log. Remaining issue will be tracked in bug 231971.
Verified fixed with 3.0RC2.
