I have a module which contains an interface, and i

Question

I have a module which contains an interface, and i

have a default implementation for this interface in that module

As well i have another module which implements this interface but but it's annotated with @Primary

currently i need to create a third module, but overide the implementation that is annotated with @Primary

any suggestions?

0

17.02.2022

3 ответов

7 просмотров

Dmytro Buryak

Since you didn't gave any details for my previous question for clarification, then I'll give you generic advices. Assume that you have 3rd partly lib "some-spring-lib", then your library you have control over called "lib-a", same type "lib-b" that depends on "lib-a", and finally the spring application "spring-app". Suggestions: - rule of thumb - never ever use @Primary in libraries, use it ONLY in applications, in your case, this is "spring-app"; this is because spring doesn't have @Secondary annotation (which designers of spring realized and added it when they designed micronaut), and as soon as you introduce "Primary" in your code, you'll mark some ipmlementation as of highest priority; thus you have to do this only in that place which is known to be not re-used in some other context where the requirements may change - if you have multiple beans of same type, you may consider using qualifiers (https://www.baeldung.com/spring-qualifier-annotation); this works best when you have multiple implementations of equal importance, which should be used at the same time in different places; example - imagine you have multiple "Cache" beans, each of which is an api for working with cached entities of different type, let's say you have "Cache of users" and "Cache of roles", "Cache of books", etc., and in one place of your code you need "Cache of users", while in other place you need "Cache of books"; qualifiers work best here, they are designed exactly for such situation, it's all about semantics (based on your question, qualifiers won't fit you) - also you can use another form of qualifiers - "named" beans, i.e. autowire/inject beans with specifying specific name of the bean (https://www.baeldung.com/spring-bean-names); the semantics and area of applicability is the same as in qualifiers; it just has different advantage/tradeoff balance - it's simpler to use, but bean names are strings which are subject to typos, and those names may become a mess in big system with many shared libraries - if you're designing shared library with spring beans, which should be "default, used uless client didn't specify anything else" principle, then check out how spring boot ecosystem does it - it has concept of "autoconfiguration" (https://www.baeldung.com/spring-boot-custom-auto-configuration), it does exactly what you seem to be doing; it's very clumsy in iplementing to be honest, but it's very easy to use when you applied it ; so in my example "some-spring-lib" uses exactly this approach, it defines beans and declares factory methods for those beans with lots of usage of @ConditionalOn... to make them overridable by users; I recommend you to use this approach as it's the most elegant and easy to use as a client of the library, but it may be not an option for you depending on the semantics of those beans; just use @ConditionalOnClass/@ConditionalOnMissingClass correctly - exclude offending beans/spring-configurations from autoscanning (https://www.baeldung.com/spring-component-scanning), or the opposite - include only specific bean with @Import(https://www.baeldung.com/spring-import-annotation ); this is not very reliable option, and is ok to be applied in end applications ("spring-app" in our example), but not in libraries - another option would be to replace beans with "BeanPostProcessor" or "BeanFactoryPostProcessor"; this is very bad and dirty solution and generally should be used for other purposes; this may be an option only when you don't have control any control over "lib-a" and "lib-b" source code, and those have obvious unresolvable conflict; so you can add bean post processor, or bean factory post-processor either in "lib-b" or in "spring-app" which takes winning "Primary" bean and replaces it with new instance of other implementation you want (yak, clumsy)

0

20.02.2022

Manav | avoid unnecessary messaging me

Dmytro Buryak
Since you didn't gave any details for my previous ...

+1

0

21.02.2022

Dmytro Buryak · Accepted Answer

Dmytro Buryak

——————— summary: - better use "autoconfiguration" approach for defining "default if not overridden" kind of beans - if not applicable, otherwise use qualifiers/bean names to specify which exactly bean impl you want - if not applicable, otherwise configure beans autoscanning/importing - otherwise try bean/bean factory post processors to replace one bean impl with other

0

20.02.2022

Похожие чаты

I have a module which contains an interface, and i

3 ответов

Похожие вопросы