@Named fails to instantiate dependency beans with type-mutating BPPs

[netikras]

ref.: https://stackoverflow.com/questions/78203201/spring-beanpostprocessor-and-inconsistently-failing-app-startup

Hello,

I have a client whose devs are building a greenfield project with Spring. They have opted in for using a custom implementation of a BeanPostProcessor. What it does is if-instanceof a particular type of beans and mutate their type (i.e. return a field of said bean that has a different type than the bean).

All was fine until we built a GitLab CI pipeline (using shared runners). For some reason, images/jars built in the pipeline failed to start with an error:

**************************
APPLICATION FAILED TO START
***************************

Description:Parameter 1 of method method1 in my.app.Application required a bean of type 'my.infra.user.UserKind' that could not be found.

Action:

Consider defining a bean of type 'my.infra.user.UserKind' in your configuration.

(class names are changed)

The issue does not occur if the jar is built on my or dev's laptop. I tried attaching a debugger in the BeanFactory and I've observed that in cases where it works, these dependency beans are already loaded into the context, and in cases where it fails (jar built in CI) -- dependency beans are not yet loaded in.

I found a workaround -- declaring all dependencies of a bean with @DependsOn. I've noticed that only beans depending on BPP-ed beans are failing to load. Regardless, I don't feel like recommending the developers to manually hardcode the dependency graph with DependsOn every time a class needs a BPP'ed bean.

I've compared the two jars: one built on my laptop (that works) and one built by CI (that won't work). Files are identical (I diffed their md5sums). The only difference was the jar's central directory -- the order of files in the archive was hugely different. I've found that the order depends on the OS and the underlying filesystem, as well as the build tools and their versions (in other words - too many moving parts).

I've also tried extracting a working jar and re-zipping it in a different order (unzip app.jar -d unzipped && cd unzipped && find . -type f | sort | while read -r file ; do zip ../reordered.jar "${file}"; done). After this modification the newly packaged jar also failed to boot with the same error (only different class names)

The findings discovered during debugging (i.e. on the failing jar, dependency classes are not yet loaded and on the working jar dependency classes are already available) AND the findings regd. the jar files' ordering suggest to me that Spring loads beans in the order they are listed in the jar's central directory. However, I don't understand why does it fail to lazy-wire (and lazy-instantiate) dependencies that are supposed to be post-processed.

Bean dependencies are correctly @Named-annotated in the bean constructor. But for some reason @Named fails to instantiate the dependency bean on time, whereas @DependsOn does it just fine.

To me, it seems like a bug. IMO the factory, when finds a @Named dependency, should behave like @DependsOn, i.e. find the dependency bean in the classloader by its name, initialize it fully and then autowire it and only then complete the bean creation.

P.S.

• 3.2.2
• 21

[snicoll]

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.

[netikras]

@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

[snicoll]

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.

[netikras]

@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?

[snicoll]

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.