Can you please add a unit test to demonstrate the problem? I don't fully understand the issue.

Also, this implementation comes with a performance penalty when accessing any resource, since additional Strings must be constructed and concatenated to generate the new path. I'd like to understand if there's a better option, for example changing the path provided by the caller.

I've created a test case which fetches a resource from a jar file. It uses a JarResourceSet with the internalPath set to /META-INF/resources and the test fetches the file /META-INF/resources/index.html. This is what happens when e.g. you have an exploded war-file containing a jar file inside /WEB-INF/lib/ and try to load a resource using servletContext.getResource("/index.html").

Without the bloom filter the test will pass, but when enabling the filter it fails due to the missing internalPath in the call to mightContainResource(...).

Regarding the performance penalty of the string concatenation, the same concatenation exists a few rows below when not using the bloom filter (line 228: String pathInJar = getInternalPath() + path.substring(webAppMount.length());) So I'm not sure if there's a better way of doing this when using the filter.

Thank you, this was very helpful! I investigated and found:

1. Your test clearly reproduced the error. Much appreciated.
2. internalPath is usually "" (a String of length 0)
3. I'm uncertain why this issue was discovered several years after the Bloom filter was added - I don't see any relevant code changes since the first merge.

Point 3 suggests that either I overlooked a recent change, or this is a very extreme edge case. If this is an extreme edge case, we should consider the performance penalty for everybody versus support for the case.

FWIW we can make that performance penalty very small by switching to this logic:

(internalPath.isEmpty ? path : internalPath() + path)

For the common case, the only extra work is a length check on a non-null String and a branch. It's not quite free but is pretty cheap.

Thanks for the very quick feedback! I'll update the code with your suggestion.

I'm guessing that the combination of having resources inside jar files and turning on the bloom filter is not that common. But both of those scenarios are nice features in larger projects. However, I do understand if the need of the many outweighs my needs.

Looks good to me. Of course, I'm not a committer. :)

Thanks for the PR. Applied manually with a few tweaks.