Running into issues with SpringComponentFinderStrategy tripping over multiple interface hits about java HOT 3 CLOSED

1. I will need to check this, but since the component finders are working on bytecode, and because of (generics) erasure, this might be the reason why both the SomethingUpdateDbConsumer and OtherthingUpdateDbConsumer are being identified as the same Consumer component.

2. The pre-built Spring component finder only has some relatively simple rules for identifying components and their interfaces, based upon the typical naming and coding conventions. With your repositories, the component finder strategy is only looking for interfaces that are assignable to CrudRepository, which will be why your implementation classes are being ignored.

For both issues, you may be better off either (1) writing your own component finder strategy, which implements the rules based upon how your codebase is structured or (2) use a different set of strategies based upon naming conventions, etc. This perhaps isn't the answer that you wanted, but FWIW, this is exactly why the client library is open source ... every codebase is structured differently, and the rules for identifying components in one codebase are usually different to others.

Hope that helps.

from java.

Wow, thanks for the lightning response.

I'm not upset by that answer in the slightest. I definitely figured my issues around the repository stuff were going to necessitate a custom finder strategy. Yay open source!

I was thinking that it might be useful for the built in spring component finder to avoid trying to use interfaces that have nothing to do with spring components. Do you see any merit in that?

from java.

I ended up creating an almost clone of SpringComponentComponentFinderStrategy that just added the following check right before it tests for an interface:

// We don't really want to name things after generic internals such as java.util.function.Consumer
if (interfaceType.getCanonicalName().startsWith("java.")) {
    continue;
}

from java.