Code scanners should exclude META-INF by default

[sschuberth]

Scanners that are only supposed to scan code (and not resources) should by default have a path filter to exclude the META-INF directory. Otherwise, if logging is enabled, the log gets cluttered with output like

09:38:56.774 [main] DEBUG org.reflections.Reflections - could not scan file META-INF/MANIFEST.MF in url file:/.../annotations-13.0.jar with scanner SubTypesScanner
09:38:56.774 [main] DEBUG org.reflections.Reflections - could not scan file META-INF/MANIFEST.MF in url file:/.../annotations-13.0.jar with scanner TypeAnnotationsScanner

for a simple call to getSubTypesOf().

[xiumeteo]

Hi, Reflections#getSubTypesOfdoesn´t actually do any scan, instead, the scanning happens when you create a new Reflections instance, then on the call of getSubTypesOfit just collect the info that we already have.

I tried to reproduce the issue and what I found is that this is happening only when you create a new instance of Reflections without passing any parameter, maybe you should try to restrict the search to a package or something similar.

[sschuberth]

The issue actually is in kotlintest which I'm using, see here:

val configClasses = Reflections().getSubTypesOf(ProjectConfig::class.java)

So kotlintest is looking for a ProjectConfig class that could be in any package. Any suggestions how to restrict the search in this case?

[sschuberth]

@xiumeteo, @ronmamo, any further hints?

[mmdemirbas]

The issue persists even if a package specified:

Reflections reflections = new Reflections(
                                 new ConfigurationBuilder()
                                      .setUrls(ClasspathHelper.forPackage("my.package"))
                                      .setScanners(new SubTypesScanner())
                                 );

Log for MANIFEST.MF:

18/01/26 07:14:26.075 DEBUG: (Reflections.java:184) going to scan these urls:
jar:file:/xxx.jar!/
jar:file:/yyy.jar!/
18/01/26 07:14:26.106 DEBUG: (Reflections.java:257) could not scan file META-INF/MANIFEST.MF in url jar:file:/xxx.jar!/ with scanner SubTypesScanner
org.reflections.ReflectionsException: could not create class object from file META-INF/MANIFEST.MF
        at org.reflections.scanners.AbstractScanner.scan(AbstractScanner.java:32) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.scan(Reflections.java:253) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.scan(Reflections.java:202) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.<init>(Reflections.java:123) ~[reflections-0.9.11.jar:?]
        ...

Log for the pom.xml:

18/01/26 07:14:26.185 DEBUG: (Reflections.java:257) could not scan file META-INF/maven/xxx/yyy/pom.xml in url jar:file:/zzz.jar!/ with scanner SubTypesScanner
org.reflections.ReflectionsException: could not create class object from file META-INF/maven/xxx/yyy/pom.xml
        at org.reflections.scanners.AbstractScanner.scan(AbstractScanner.java:32) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.scan(Reflections.java:253) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.scan(Reflections.java:202) ~[reflections-0.9.11.jar:?]
        at org.reflections.Reflections.<init>(Reflections.java:123) ~[reflections-0.9.11.jar:?]
        ...

[joewhite86]

@mmdemirbas can you try with 0.9.10?
I have the assumption that this is broken since 0.9.11

[ymamakis]

Hi there, Can it be related to this?
pact-foundation/pact-jvm#382

[chris-orchard]

Using 0.9.11 I get a similar issue with warnings about .sql files etc. Supplying the package didn't help (the .sql files are in the same directories as some classes).

Instead after lots of trial and error I found I needed to use filterInputsBy this:

new Reflections(new ConfigurationBuilder()
        .setUrls(ClasspathHelper.forPackage(OUR_PACKAGE))
        .setScanners(new SubTypesScanner(true), new TypeAnnotationsScanner())
        .filterInputsBy(new FilterBuilder().include(".*class")) // only scan classes (exclude *.sql.stg files etc) to prevent warnings in console
);

However I agree that this might be best as default behaviour, or at least a simple method call to enable this behaviour. It's a lot of boilerplate for what I assume will be the most common use. Some clearer details on this in the docs and example on how to limit to just classes would help.

[xaviersd77]

I came across same issue, seeing exceptions when debug enabled, and this got fixed after upgrading to 0.9.12. Hope this helps someone..!
Main issue was in 0.9.11 scan method had : if (scanner.acceptsInput(path) || scanner.acceptResult(fqn))
and in 0.9.12 it is changed to: if (scanner.acceptsInput(path) || scanner.acceptsInput(fqn))