[
https://issues.apache.org/jira/browse/VFS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945198#comment-16945198
]
Gary D. Gregory commented on VFS-299:
-------------------------------------
Hi [~josua.troesch]
May you please provide a failing unit test as a PR on GitHub so we can really
see what you found...
Gary
> 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)
