matchClassesWithAnnotation() does not match anything (1.9.11)

[moldowan]

matchClassesWithAnnotation() does not match anything (1.9.11)

[lukehutch]

Note that to find annotation javax.persistence.Entity, you must have javax.persistence in your whitelisted path list. This didn't use to be the case, the whitelist would "spill over" by one link if a class in a non-whitelisted package was referenced by a whitelisted path. I made the whitelisting "hermetic" in 1.9.10, so only classes in whitelisted packages are matched or returned.

I suspect this is the problem you are running into, since all of the annotation types you listed are in third-party packages, but please verify. Meanwhile, I'll update the docs to make this more explicit.

[lukehutch]

Just released 1.9.15, please try with that version.

[moldowan]

With 1.9.15 I get:
java.lang.IllegalArgumentException: Can't scan for javax.jws.WebService, it is in a package that is either blacklisted or not whitelisted
While this now clearly points to the problem, I find it pretty counterintuitive to include something that I do not want to scan for.

What if javax.persistence contained a class that is annotated with javax.persistence.Entity?
I guess adding javax.persistence to scanSpec would match that class too. This is not what I want and I'm inclined to say that most users would not expect this behaviour.
I my point of view (from a strict user perspective), javax.persistence.Entity is just a "matcher criteria", not something I want to scan for.

Am I making sense?

[lukehutch]

Yes, that makes sense. What if you could whitelist class names, not just package names, in the scanning criteria? e.g. new FastClasspathScanner("com.mypkg", "+javax.persistence.Entity") -- would this work for you?

[moldowan]

Well, this would be a workaround.
The major downside of this is that you need to "duplicate" all annotations and classes you use in the the matcher methods. This is especially cumbersome if you add a dynamic number of processors.
Couldn't the scanner just auto-add the classes/annotations from the match-invocations?

Why do you need to "scan" for javax.persistence.Entity in the first place?
Do you read it's bytecode? If yes, why?

[lukehutch]

No, the bytecode is not read. It was an intentional change to be clean, since methods like getNamesOfAllClasses() / getNamesOfAllAnnotations() were returning what could amount to a large number of classes that weren't even whitelisted. Maybe I can just add a method like .includeReferencedClasses() to not exclude these.

[moldowan]

In my opinion the class parameters of the match... invocations should not be included in any of the lists (getNamesOfAllClasses() etc.).
So .includeReferencedClasses() does not fit 100%.

I wouldn't call those class parameters "referenced" at all.
To be fair, javax.persistence.Entity is in deed referenced by each entity class but the class parameters are a different thing.

[lukehutch]

You raise good points -- I implemented this with the semantics you suggested. See the entry in the docs about this. I think this will do what you need, but if not, please re-open. Will push out 1.9.16 with this fix.

[lukehutch]

Does 1.9.16 work as you expect?

[lukehutch]

I added a couple more fixes for this, let me know if it doesn't work for you. I'll push out 1.9.17 with these fixes.

[moldowan]

I haven't had the time to test 1.9.16 or .17 yet, but I will do so in the next two weeks or so.

[lukehutch]

OK, thanks. Skip 1.9.16, it won't work for you, you'll need 1.9.17.
On Jan 20, 2016 2:52 AM, "moldowan" [email protected] wrote:

I haven't had the time to test 1.9.16 or .17 yet, but I will do so in the
next two weeks or so.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.