[camel-master branch] support ComponentNameResolver

[lburgazzoli]

See: apache/camel@2e57fd7

[lburgazzoli]

@gnodet @jamesnetherton is someone of you already working on this ?

[jamesnetherton]

@lburgazzoli is there anything specific that needs to be done for this?

I tested it on the master branch and it seems to be working fine.

[lburgazzoli]

@jamesnetherton not I'm aware of, was thinking to have this process done at build time so basically have a component name resolver that returns a static list of component names but maybe it is not needed.

[lburgazzoli]

@jamesnetherton I think this has been already fixed right ?

[jamesnetherton]

I need to revisit this, I started work on it but stopped for some reason that I now forget.

[jamesnetherton]

I finally got around to taking another look at this. Is the intention that CamelContext.getComponentNames would leverage this?

If so the signature for that method and ComponentNameResolver.resolveNames has an incompatible return type. Set Vs List, so Camel would need modifying.

[lburgazzoli]

@davsclaus may know

[davsclaus]

Yeah Set would be better api as component names are unique

[davsclaus]

Created a JIRA
https://issues.apache.org/jira/browse/CAMEL-16822

[davsclaus]

Okay changed the API in Camel 3.12

[omnipitous]

@davsclaus @jamesnetherton Dependency updates being what they are... discovering this a year later. SO: Changing from List to Set is a breaking change that should not have been included in a Minor release. Specifically, I ran into this issue because the dropwizard-camel-core package calls on this method for its health check and expects a List in response so upgrading past 3.11.0 of camel-api broke that library.

[oscerd]

What do you mean with dependencies updates are what they are?

[omnipitous]

What do you mean with dependencies updates are what they are?

Meaning for a load of real world reasons we're not updating all of our dependencies relentlessly. *Especially when they are largely transitive dependencies of other dependencies that have interweaving version locks. (Such as Camel and Dropwizard) AND when we frequently run into breaking changes such as this one. I would love to just have Dependabot keep all of our deps current all the time BUT that's not the world of stability we live in.