The DirectorySnapshot uses the filter to filter possible changed files:
private Set<FileSnapshot> filter(Set<FileSnapshot> source, FileFilter filter) {
if (filter == null) {
return source;
}
Set<FileSnapshot> filtered = new LinkedHashSet<>();
for (FileSnapshot file : source) {
if (filter.accept(file.getFile())) {
filtered.add(file);
}
}
return filtered;
}
The DirectorySnapshot uses the negated filter result to accept changed files:
private boolean acceptChangedFile(FileFilter triggerFilter, FileSnapshot file) {
return (triggerFilter == null || !triggerFilter.accept(file.getFile()));
}
Result is always an empty changeset when a filter is applied!
Comment From: wilkinsona
Thanks for the report but I don't think your analysis is correct. We have a test for the file system watcher with a trigger filter applied:
https://github.com/spring-projects/spring-boot/blob/a1f3bbc895b61c5ee3dcc6b8d5ed0b1ddb26ba4e/spring-boot-project/spring-boot-devtools/src/test/java/org/springframework/boot/devtools/filewatch/FileSystemWatcherTests.java#L255-L274
First, file.txt is modified and no changed files are found. The trigger file, trigger.txt, is then modified and the file system watcher then notices that file.txt has been modified.
Can you please illustrate the problem that you've found with a unit test of your own or with a minimal sample and the necessary steps for us to reproduce it?
Comment From: thmueller1
Hello,
then i totally misunderstood the meaning of this filter. My purpose was to minimize the files in the given directories that should be watched by the watcher. That seems to work because only those given files are collected to build the changeset. But in that methode exactly those files where filtered out so the changeset is always empty.
Comment From: wilkinsona
The filter is intended to support using a specific trigger file to trigger a dev tools restart. The trigger file is deliberately filtered out from the change set as it isn't part of the application.