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

Reply via email to