commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <j...@apache.org>
Subject [jira] [Work logged] (VFS-299) Listeners on DefaultFileMonitor not deregistered on stop()
Date Wed, 09 Oct 2019 13:37:00 GMT

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

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

                Author: ASF GitHub Bot
            Created on: 09/Oct/19 13:36
            Start Date: 09/Oct/19 13:36
    Worklog Time Spent: 10m 
      Work Description: garydgregory 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: 325696)
    Time Spent: 20m  (was: 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: 20m
>  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)

Mime
View raw message