commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary D. Gregory (Jira)" <j...@apache.org>
Subject [jira] [Commented] (VFS-299) Listeners on DefaultFileMonitor not deregistered on stop()
Date Mon, 07 Oct 2019 16:13:00 GMT

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

Gary D. Gregory commented on VFS-299:
-------------------------------------

Hi [~josua.troesch]

The reason for asking for a PR instead of pointing to a URL with some code is for you to provide
a test that we can use now as opposed to cherry-picking it from a larger set and rewriting
the code to provide a working test. For example, the code at the URL [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/FileMonitorAddRemoveTest.java] does
not compile since it uses "var", a Java 10 feature, while Commons VFS is on Java 8.

Providing a PR minimise the friction and time wasting for bringing new test code into this
component and allows maintainers like me to focus on analysis and bug fixing instead of the
mechanics of importing and fixing code which includes the risk of changing that code in subtle
ways that do not reflect the intent of the original post. We maintain a lot of code in Apache
Commons ;)

Thank you for your understanding,
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)

Mime
View raw message