Support for Named Multiple ConnectionFactories

[vkasala]

Support for multiple named connection factories similar to Quarkus datasources

• https://quarkus.io/guides/datasource#multiple-datasources

[turing85]

Hey! We are right now in the process of implementing this part for quarkus-artemis (ticket, MR). Since @Named is discouraged, we are debating whether to use @Identifier or a custom qualifier annotation. We thought it might be a good idea to reach out and see what you guys think, so we can follow a common approach. Do you have any opinions on this one? We favor providing a custom scope annotation (i.e. @Connection).

[gemmellr]

I dont know anything about those bits so have no idea what is recommended / discouraged / appropriate / preferred or why. If others have their own then maybe thats the way to go. Might it even allow using the two extensions with injection at the same time?@Connection doesnt seem like a great/obvious annotation name to me for naming a ConnectionFactory instance though.

[turing85]

I dont know anything about those bits so have no idea what is recommended / discouraged / appropriate / preferred or why. If others have their own then maybe thats the way to go. Might it even allow using the two extensions with injection at the same time?

The artifact(s) is (are) still exported as a bean(s), so injection (when unambiguous) works "as expected" with @Inject. For named connection factories, however, the injection might either be ambiguous or always inject the default bean (which is most probably the default/unnamed connection factory). So in order to inject named connection factories, we have to somehow qualify what connection factory to inject. Using @Named is discouraged (please see the link above). This leaves us basically with two options: use SmallRye's @Identifier(...) or provide a custom @Qualifier-annotation (just like datasources do with @DataSource). It is - in theory - possible to use both @Identifier(...) and a custom @Qualifier-annotation, but this might be a case where providing less choice might be better.

@Connection doesnt seem like a great/obvious annotation name to me for naming a ConnectionFactory instance though.

The name is tbd. For our extension, we do not necessarily provide connection factories, but either connection factories or server locators, hence my choice for @Connection. But as I said: this is still tbd. My core concern is that we get some coherence on the mechanism we use. You would obviously be free to choose your own name :)

[gemmellr]

I did read your link etc before replying, I just dont actually use the injection stuff anywhere personally (copied the stuff for the extension) and so have no real experience/understanding of much of it and thus whats best.

I guess using @Identifier would allow them both to use the same thing which would be nicer for consistency and switching. Given that the 'ConnectionFactory' type isn't extension-specific it seems like it would be nice if any 'just specifying a config-associating name' annotation wasnt extension-specific either. Thinking on it again, I dont actually recall any great argument for using a custom one besides 'nicer javadoc' which seems a thin argument in this case given all its actually doing, and I believe it was also mentioned @Identifier was simpler (I see we already depend on its dep)? I think I'd go with the simple and more-generic option for now, short of a convincing reason not to.

The name of any custom annotation still being TBD is why I'm commenting now rather than later; using @Connection isnt obvious to me for naming either a ConnectionFactory or a ServerLocator. (@Identifier on the hand, seems to match up well for assocating a name to pretty much anything?).

[turing85]

Okay, we will then use @Identifier as well :) thanks for the clarification!