spring - Implicit dependency between BeanNameAutoProxyCreator and imported configuration -
at company, we're working on aspect-oriented trace interceptor, similar debuginterceptor
. we're configuring customizabletraceinterceptor
, using beannameautoproxycreator
auto-proxy beans aop.
the problem we're facing that, when introduce beannameautoproxycreator
in configuration:
@configuration @import(bconfig.class) @enableaspectjautoproxy public class aconfig { @bean public static beannameautoproxycreator beannameautoproxycreator() { beannameautoproxycreator beannameautoproxycreator = new beannameautoproxycreator(); beannameautoproxycreator.setinterceptornames(new string[] {debug_interceptor_name}); beannameautoproxycreator.setbeannames(new string[] {beans_names_expression}); return beannameautoproxycreator; } }
we org.springframework.beans.factory.nosuchbeandefinitionexception: no qualifying bean of type [x], x resteasy proxy. resteasy proxy declared in bconfig
.
now, if move resteasy proxy bean configuration aconfig, issue solved, , @dependson
solves issue too.
my questions 3: when spring able resolve dependencies between beans? why using beannameautoproxycreator changes behavior? recommended way of solving issue (beanpostprocessor, @dependson, etc.).
the static beannameautoproxycreator
depends on normal bean (probably due beans_names_expression). because static loaded/bootstrapped before other beans , before bean processing @import
. when analyzing beans process, bconfig
hasn't yet been loaded. why works when move bean aconfig
or @ depends-on bean.
i revert use of beannameautoproxycreator , rely on @enableaspectjautoproxy
aspect using bean pointcut attach desired interceptor.
there risk in introducing beannameautoproxycreator
next @enableaspectjautoproxy
can lead proxy of proxy being created, due 2 different aop strategies/mechanisms.
Comments
Post a Comment