[jira] [Commented] (VFS-299) Listeners on DefaultFileMonitor not deregistered on stop()

["Falco (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VFS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944384#comment-16944384 ] 

Falco commented on VFS-299:
---------------------------

Despite being more than nine years old, I believe this issue still relevant. I took the liberty to archive above example code in a runnable example project: [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/MinimalFileMonitorBug.java]

To my opinion, I do not know if {{stop}} should remove the listeners. This would remove the functionality to pause listening for file events using {{stop}}, and to resume listening for the same files with {{start}} (without re-registration of said files).

If a method removed filesystem listeners, it should be {{removeFile}}. This appears logical to me, since {{addFile}} registered the filesystem listener.
In fact, adding, removing, and re-adding file registrations to the file monitor triggers doubles the change events as demonstrated in [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/FileMonitorAddRemoveTest.java].

Suggestions:
* Let {{DefaultFileMonitor#removeFile}} remove the file system listener.
* Decide what happens on {{DefaultFileMonitor#stop}}:
** Keep the current state: it's duty of the client code to remove all file registrations after calling {{stop}} *or*
** Alter behavior and make {{stop}} remove all registrations of watched files using (fixed) {{removeFile}} (with implications described above)



> Listeners on DefaultFileMonitor not deregistered on stop()
> ----------------------------------------------------------
>
>                 Key: VFS-299
>                 URL: https://issues.apache.org/jira/browse/VFS-299
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: windows xp
>            Reporter: Josua Troesch
>            Priority: Minor
>
> If I 
> 1. register a File to a DefaultFileMonitor
> 2. stop() that DefaultFileMonitor
> 3. create a new DefaultFileMonitor and
> 4. register the same File to it
> 5. write to the File
> I get the {{FileChangeEvent}} on both listeners, on the one registered to the new DefaultFileMonitor (as expected) but also on the one registered to the stopped DefaultFileMonitor. I tracked it down to the {{LocalFileSystem.listenerMap}} containing both listeners for the File. In my project I fixed this behaviour as follows:
> Extended the {{stop()}} method on {{DefaultFileMonitor}}:
> public void stop() {
>     this.shouldRun = false;
> 	// Inserted this bit
> 	for (FileMonitorAgent agent : (Collection<FileMonitorAgent>)monitorMap.values()) {
> 		agent.removeListeners();
> 	}
> }
> And adding the method to the {{DefaultFileMonitor$FileMonitorAgent}}:
> public void removeListeners() {
> 	file.getFileSystem().removeListener(file, fm.getFileListener());
> }



--
This message was sent by Atlassian Jira
(v8.3.4#803005)