I have an application that imports a @Configuration from an external dependency, a configuration I cannot modify. This configuration creates a scoped bean (specifically, a @StepScope bean for a Spring Batch @Step definition) and I need to intercept the bean before the actual instantiation for further customization (i.e., setting additional properties).

I started implementing a BeanPostProcessor but I quickly realized I would have access to the proxy and not to the actual instance since it is a scoped bean. Looking at the Container Extension Points section, I couldn't find any alternative solutions. However, after looking at the sources, I found that InstantiationAwareBeanPostProcessor exposes exactly the callbacks I would need.

The Javadoc states that:

NOTE: This interface is a special purpose interface, mainly for internal use within the framework. It is recommended to implement the plain BeanPostProcessor interface as far as possible.

I could not find a cleaner solution for such a use case than implementing this interface.

May I ask to reassess its purpose? The interface is anyway public and nothing prevents its usage, so mine is mostly a Javadoc update request.

In case the interface is accepted for public usage, I believe its discoverability could be further improved with at least a brief mention in the reference documentation. I would be happy to compose an addition for the Customizing Beans by Using a BeanPostProcessor section.

Comment From: snicoll

The interface is anyway public and nothing prevents its usage

I am not sure I see the argument. We're using it as a framework extension points in various areas so it being public does not give us much of a choice. Besides, if we managed to make it package-private there wouldn't be any need for a note in the Javadoc.

May I ask to reassess its purpose?

I don't think we should. What you've described fits exactly the intention of the interface. I can see how the discoverability can be improved for advanced usage. Would you have the time to configure a short note?

Comment From: scordio

I am not sure I see the argument.

Sorry, maybe I didn't phrase it properly a year ago 😅 My request was only for Javadoc content:

NOTE: This interface is a special purpose interface, mainly for internal use within the framework. It is recommended to implement the plain BeanPostProcessor interface as far as possible.

The impression I had after reading it is that its use outside the framework is not recommended, but perhaps I misunderstood.

I have no issue with the current visibility. If it weren't public, I would have no chance to use it for my use case 🙂

Would you have the time to configure a short note?

Yes, absolutely! Should I only contribute to the reference documentation or do you also expect an update of the Javadoc, especially to highlight that it is allowed to use it outside the framework?

Comment From: snicoll

The impression I had after reading it is that its use outside the framework is not recommended, but perhaps I misunderstood.

That is correct.

do you also expect an update of the Javadoc, especially to highlight that it is allowed to use it outside the framework?

I do not. It's really not recommended. But it's not forbidden either. We could also go the other way and understand why you need to use this but that would be a different discussion.

Comment From: scordio

We could also go the other way and understand why you need to use this but that would be a different discussion.

I explained it at the beginning of the issue:

I have an application that imports a @Configuration from an external dependency, a configuration I cannot modify. This configuration creates a scoped bean (specifically, a @StepScope bean for a Spring Batch @Step definition) and I need to intercept the bean before the actual instantiation for further customization (i.e., setting additional properties).

and one year later, I can confirm that the use case is still valid and has appeared more in the environment I'm working on.

Comment From: snicoll

You described it, but we didn't have a chance to look further to asses this was the proper/only way of doing things. Again, I don't think this is the right place to discuss this but you're the one asking for a change in our policy.

If you want to submit a PR to improve the doc, please do so and we can continue the discussion there.

Comment From: scordio

Sure, got it. Will do!