Community
Participate
Working Groups
1. Create a Unix connection and connect to the system 2. Create a filter with the name "file.filter" 3. Show "Project Explorer" view and create a general project 4. Drag the filter and drop to the project The following error dialog is shown: RSEG1106E File NISHIMOTO.zos18.unix.interface org.eclipse.rse.services.files.IFileService.NISHIMOTO.CN-zos18.unix-dstore.files.file.filter not found on host zos18.unix This error message is not shown for a filter without a period, like "file".
I've committed a fix for this.
I tried to understand this change, but failed. Here are a couple questions: 1. In SubSystem#getFilterReferenceWithAbsoluteName(), how is the "absolute name" for a filter defined? Please improve the Javadocs to add specification of how an absolute name is supposed to be built. 2. The code first replaces . by , and then splits by , -- this leads to loss of information which doesn't seem wise. 3. What is the expected semantics of dragging a filter into a project? Is it to copy all files referenced by the filter? 4. To make the code more readble, consider using methods for common operations (e.g. join a subset of segments with "." into a String) I'm not comfortable releasing this change into 3.2.1 unless I understand it. Thanks!
(In reply to comment #2) > I tried to understand this change, but failed. Here are a couple questions: > > 1. In SubSystem#getFilterReferenceWithAbsoluteName(), how is the "absolute > name" for a filter defined? Please improve the Javadocs to add > specification of how an absolute name is supposed to be built. > > 2. The code first replaces . by , and then splits by , -- this leads to loss > of information which doesn't seem wise. > > 3. What is the expected semantics of dragging a filter into a project? Is > it to copy all files referenced by the filter? > 1. The absolute name for a filter reference is determined via a call on it's view adapter to getAbsoluteName(Object). Ultimately, this ends up as the following: <profile name>.<host alias>.<service type>.<filter pool manager name>.<filter pool reference name>.<filter name> Unfortunately, the use of . as a separator leads to some ambiguity but I don't think we can change this format now. 2. Since apparently comas are valid characters in filter names, perhaps a different delineator ought to be used for the split. 3. I don't believe we support the dragging of a filter into an Eclipse project right now. I think, in Masao's case, there is a customized Project Explorer with special remote projects.
Ping - I'm still not comfortable releasing this into 3.2.1 as-is since I cannot understand the code.
(In reply to comment #4) > Ping - I'm still not comfortable releasing this into 3.2.1 as-is since I cannot > understand the code. What the code does is determine what the filter reference object is for a given key. As mentioned before, the key is of the following form: <profile name>.<host alias>.<service type>.<filter pool manager name>.<filter pool name>.<filter name> To determine the filter reference object, we first need the right filter pool manager. The filter pool manager is determined by using the profile name (the first segment) to get the corresponding filter pool manager for the known subsystem configuration. Then we need to determine the right filter pool within the filter pool manager. The code iterates through the filter pools trying to find a match based on the key. We would normally expect the filter pool name to be identified as the penultimate segment of the key, however the problem we hit with this defect is that, if a filter pool or a filter name contains one or more dots (which are used as deliminators), the filter pool will not be the 2nd to last segment. To deal with those cases, we walk up the segments looking for an existing filter pool name based on combined segments. Once the filter pool is determined, we're able to find the filter name based on the remaining segments of the key.
Ok. I understand the description, but I still find the code problematic - hard to read. What about splitting out a "joinSegments" method and doing like this (pseudocode): for(int split = segments.length-2; split>1; split--) { poolName = joinSegments(segments, 1, split, '.'); if (mgr.hasPool(poolName) { filterName = joinSegments(segments, split, segments.length, '.'); if (mgr.getPool(poolName).hasFilter(filterName) { break; } } } A yet better option would not even split the String into segments, but just remember the index of each '.' or ',' character in an indexArray, and then perform String.substring() as needed to get the segments. This would preserve the "." vs "," characters and thus potentially allow "my,filter" to be found (not sure if that's relevant though).
The fix has been released to HEAD (3.3) but *not* to the maintenance stream because I still find the code hard to read and understand, and I see some potential risk. If you need a backport to 3.2.2, please open a separate bug for discussion.
