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

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot logged work on VFS-299:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 09/Oct/19 07:05
            Start Date: 09/Oct/19 07:05
    Worklog Time Spent: 10m 
      Work Description: f4lco commented on pull request #72: VFS-299 Add failing tests for missing filesystem listener removal in DefaultFileMonitor
URL: https://github.com/apache/commons-vfs/pull/72
 
 
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 325509)
    Remaining Estimate: 0h
            Time Spent: 10m

> 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
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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)