[
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)
