@Named fails to instantiate dependency beans with type-mutating BPPs about spring-framework HOT 5 CLOSED

You should not mutate the type of a bean in a BeanPostProcessor in the first place. Bean post processing is meant to eventually wrap the target instance as hinted by the Javadoc:

The returned bean instance may be a wrapper around the original.

If you mutate the type, then you're exposing yourself to the issue you've described, with changing the bean dependency graph is a way to get things working as the container will have the effective type to match against.

from spring-framework.

@snicoll

Thank you for the clarification.

FWIW "wrapper" is a broad term, by no means limited to "the same type as the wrapped element". Wrappers can be used for encapsulation, extension, as Facades or whatever the developer's heart desires. Perhaps it's worth mentioning in the docs explicitly that the wrapper (if used) must have the original bean's type signature in its inheritance hierarchy. Is it perhaps possible to enforce this by using the same generic type in the BPP's method's argument and a return type instead of a wildcard Object?

from spring-framework.

You are mistaken. I already mentioned above that the type you return can be restricted, or can be expanded so that generic type idea makes no sense.

FWIW "wrapper" is a broad term, by no means limited to "the same type as the wrapped element".

Where did I say that a wrapper has to be the same type as the wrapper element (since you seem to be quoting something)? Perhaps looking at a class in the JDK might help?

BeanPostProcessor is a low-level contract so we need to provide the flexibility as a framework. If you decide to return a completely different hierarchy for a bean, so be it but then don't complain if wiring has the side effect you've experienced is all I am saying.

I think the issue has run its course now.

from spring-framework.

@snicoll

The returned bean instance may be a wrapper around the original

Does that mean the wrapper must be of the same type as the initial bean? The docs don't specify this explicitly

from spring-framework.

Like any wrapper in Java, I am assuming you're familiar with the concept. It could be an interface of the bean, or it could implement an additional interface or something like that.

The original point is that if you have a bean of type A and then replace it with a bean of type B and then expect to be able to inject a bean of type B, you are misusing the API as indicated by the Javadoc excerpt I've shared.

from spring-framework.