• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Inject a Bean based on Configuration from Database or Properties File

 
Marshal
Posts: 4542
572
VSCode Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to be able to inject a Bean with an implementation which is determined at start-time from configuration data stored in a database or properties file (not a DD).

The problem is that since there are multiple implementations, plus my Provider which provide the same type, I am seeing an AmbiguousResolutionException exception:
The solution probably involves using qualifiers for the two implementations, but I struggling to get this to work
I understand that using Named qualifiers will not work because the presence of Named will not remove the implicit Default qualifier.

I am continuing to work on this, but would appreciate if anyone would share some wisdom on what I should be looking at - maybe my approach is flawed.



 
Sheriff
Posts: 22788
131
Eclipse IDE Spring Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
At work we've once done this, and it was indeed solved with qualifiers. We had a qualifier annotation with a specific value which we used to annotate our beans that implemented an interface. We then injected an Instance of the interface. We then used its select method to find the correct bean implementation(s). AnnotationLiteral can be used to provide the annotation to use with the select method.
 
Ron McLeod
Marshal
Posts: 4542
572
VSCode Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Rob - I've got it working now, and it is cleaner than what I had before.

The only issue I have now is the warning with my class which extends AnnotationLiterial: The annotation type BasestationTypeQualifier should not be used as a superinterface for BasestationTypeLiteral - basically saying that one should not implement an annotation.  The followed the example in the javadoc, but it would also have this same warning.  I've seen a number of people with this same problem, but haven't seen any resolution.

I'll continue to try and find a way to get rid of the warning, but for now, I'm happy that it works.

This is what I ended-up with:
 
Rob Spoor
Sheriff
Posts: 22788
131
Eclipse IDE Spring Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ron McLeod wrote:The only issue I have now is the warning with my class which extends AnnotationLiterial: The annotation type BasestationTypeQualifier should not be used as a superinterface for BasestationTypeLiteral - basically saying that one should not implement an annotation.  The followed the example in the javadoc, but it would also have this same warning.  I've seen a number of people with this same problem, but haven't seen any resolution.


Ah yes, that nice little warning. I have one project that is just about warning free, apart from that one. The warning makes sense from a JSE perspective, as you shouldn't supply your own annotation implementations. For JEE however this is a good example of a valid use case.

There is possibly one work-around I found - provide a utility class for each annotation so you can use reflection to retrieve the annotation. That's even uglier though.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic