Tracking down cause of Spring's not eligible for auto-proxying
Just to bring some closure to this question, the collapse of the uninitialized object graph was caused by the BeanPostProcessor
using @Autowired
to get its dependencies, and the autowire mechanism effectively caused every other bean definition to be initialized before my BeanPostProcessor
got a chance to have a say in the matter. The solution is not to use autowiring for your BPPs.
spring security not eligible for auto-proxying
This is a fairly normal message. A BeanPostProcessor
is a Spring construct for altering/wrapping/proxying beans in the context. Because of the way the context lifecycle works, some things have to be configured before the BeanPostProcessor
get a look in, which leads to that message.
It's almost never anything to worry about, hence the INFO level. The components that trigger the message are usually Spring's own internal components.
Class not eligible for getting processed by all BeanPostProcessors
This warning means nothing, you shouldn't worry about it since you don't need to apply any post-processors to the DataSource
.
Technically it means that some bean post-processor (a transactional one, I guess) depends on your DataSource
, therefore the DataSource
must be fully initialized before initialization of that post-processor, so that the post-processor cannot intercept initialization of the DataSource
.
You need to worry if you get such a warning about a bean you want to apply post-processors to.
add module spring integration redis which print out XXX is not eligible for getting processed by all BeanPostProcessors
Those are just INFO log messages. Fully harmless. you probably didn't turn on the INFO for the whole org.springframework
category to see much more similar messages from other projects.
In fact the first 3 just say us that default bean are going to be created. We may consider to move those messages to the DEBUG or even TRACE level though...
The one for the IntegrationManagementConfiguration
doesn't matter because this one is a @Configuration
class and probably no one of them "is eligible for getting processed".
The last one for the Disposables
also doesn't matter since this class is package protected and no one really is going to post-process it somehow.
The most dangerous in your logs is that one for the BeanFactoryChannelResolver
, but as long as you use whatever the framework provides for you everything is going to be good.
Bean 'x' of type [TYPE] is not eligible for getting processed by all BeanPostProcessors
My guess is that your pointcut execution(* *(..))
(which basically says "intercept the world") affects too many components, even Spring-internal ones. Just limit it to the classes or packages you really want to apply your aspect to, e.g.
execution(* my.package.of.interest..*(..))
or
within(my.package.of.interest..*) && execution(* *(..))
You could also exclude the ones you don't need woven if that is easier to specify:
!within(my.problematic.ClassName) && execution(* *(..))
or
!within(my.problematic.package..*) && execution(* *(..))
BTW, of course your aspect needs to be a @Component
when using Spring AOP (not AspectJ).
Bean 'advisor' of type [org.springframework.aop.support.DefaultPointcutAdvisor] is not eligible for getting processed by all BeanPostProcessors
This is a quote from Spring documentation
BeanPostProcessors and AOP auto-proxying
Classes that implement the BeanPostProcessor interface are special, and so they are treated differently by the container. All BeanPostProcessors and their directly referenced beans are instantiated on startup, as part of the special startup phase of the ApplicationContext. Next, all those BeanPostProcessors are registered in a sorted fashion - and applied to all further beans. Because AOP auto-proxying is implemented as a BeanPostProcessor itself, no BeanPostProcessors or directly referenced beans are eligible for auto-proxying, and thus do not have aspects woven into them.
For any such bean, you should see an info log message: “Bean foo is not eligible for getting processed by all BeanPostProcessor interfaces (for example: not eligible for auto-proxying)”.
So, this is because Advisor
bean participates very early in application bootstrap. This is probably ok, if you wanted it, and the warning you get is not a problem, but just a reminder.
Related Topics
The Most Sophisticated Way for Creating Comma-Separated Strings from a Collection/Array/List
Copying Text to the Clipboard Using Java
Things Possible in Intellij That Aren't Possible in Eclipse
How to Check a Uploaded File Whether It Is an Image or Other File
Are There Any Other Java Libraries for Bonjour/Zeroconf Apart from Jmdns
How to Convert a Word Document to PDF
Constructor Synchronization in Java
Can Hibernate Work with MySQL's "On Duplicate Key Update" Syntax
Better Way to Create Aes Keys Than Seeding Securerandom
How to Cast from List<Double> to Double[] in Java
What's the Purpose of Meta-Inf
Java Static Serialization Rules
How to Create an 2D Arraylist in Java
How to Calculate the Number of Days in a Period
Why Is My Jlabel Not Showing Up
Should You Call Releasestringutfchars If Getstringutfchars Returned a Copy