Spring：拡張Beanはいつ祖先と互換性がないのですか？

Question

私は2つの定義されたコンポーネント

クラスA

package a; 

@Component 
@Order(Ordered.HIGHEST_PRECEDENCE) 
class A extends OncePerRequestFilter { 

クラスB私の春（ブート4.2.5）アプリケーションでこの二つの成分を使用して

package b; 

@Component 
@Order(Ordered.HIGHEST_PRECEDENCE) 
@Primary 
class A extends a.A { 

を持って、私は次のエラーを取得しています：

... 
nested exception is org.springframework.context.annotation. 
ConflictingBeanDefinitionException: 
Annotation-specified bean name 'a' for bean class [a.A] conflicts with existing, 
non-compatible bean definition of same name and class [b.A] 

私は期待していましたto）、b.Aはa.Aの代わりに使用され、置き換えられる。

なぜこのエラーメッセージが表示されますか？ b.Aを「コンポーネントa」としてどのように使用できますか？

例外/スプリントブート起動エラーのフル

：異なるパッケージから同じBeanがサポートされていないかのように

Application startup failed","stack_trace":"o.s.c.a.ConflictingBeanDefinitionException: 
Annotation-specified bean name 'httpAccessLogFilter' for bean class [b.A] conflicts with existing, 
non-compatible bean definition of same name and class [a.A] 
at o.s.c.a.ClassPathBeanDefinitionScanner.checkCandidate(ClassPathBeanDefinitionScanner.java:320) 
at o.s.c.a.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:259) 
at o.s.c.a.ComponentScanAnnotationParser.parse(ComponentScanAnnotationParser.java:137) 
at o.s.c.a.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:268) 
at o.s.c.a.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:232) 
at o.s.c.a.ConfigurationClassParser.parse(ConfigurationClassParser.java:199) 
at o.s.c.a.ConfigurationClassParser.parse(ConfigurationClassParser.java:168) 
... 16 common frames omitted 
Wrapped by: o.s.b.f.BeanDefinitionStoreException: Failed to parse configuration class [a.SpringBootApplication]; 
nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: A 
nnotation-specified bean name 'a' for bean class [b.A] conflicts with existing, non-compatible bean definition of same name and class [a.A] 
at o.s.c.a.ConfigurationClassParser.parse(ConfigurationClassParser.java:182) 
at o.s.c.a.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:321) 
at o.s.c.a.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:243) 
at o.s.c.s.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:273) 
at o.s.c.s.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:98) 
at o.s.c.s.AbstractApplicationContext.invokeBeanFactoryPostProcessors(Abst... 

Answer 1

は思えます。春で

"considers them as compatible when the existing bean definition comes from the same source or from a non-scanning source." ClassPathBeanDefinitionScanner:isCompatible

、これはまだ自分の課題トラッカーで議論され、SPR-14665とSPR-10808を参照してください。

私は醜い回避策を得ました。 祖先は別の名前を取得し、「ConditionalOnMissingBean」という注釈が付けられます。

祖先：

package a; 

@Component 
@Order(Ordered.HIGHEST_PRECEDENCE) 
@ConditionalOnMissingBean(name = "a") 
class AncestorOfA extends OncePerRequestFilter { 

クラスB：私は自分のものを実装したくない場合は

package b; 

@Component 
@Order(Ordered.HIGHEST_PRECEDENCE) 
class A extends a.AncestorOfA { 

このように、私は、コンポーネント "ancestorOfA" を持っています。独自のバージョンを使用する場合は、コンポーネント "a"は使用しますが、 "ancestorOfA"は使用しません。

明らかに欠点は、子コンポーネントの名前が正しく指定されていることです。