Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism to be notified that a bean has been created [SPR-16822] #21362

Open
spring-issuemaster opened this issue May 14, 2018 · 3 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented May 14, 2018

Andy Wilkinson opened SPR-16822 and commented

We have some code in Spring Boot that's intended to perform initialisation of a DataSource just before it's first made available to application code. It currently uses a BeanPostProcessor and uses the post-processing of any DataSource as the trigger for initializing a DataSource. For reasons that escape me, this DataSource may not be the same DataSource as the one that is being post-processed so it performs a lookup of a bean while another bean is being post-processed. That has caused several problems.

I think we could simplify the above-described logic so that we only perform initialisation of the DataSource bean that is being post-processed, thereby avoiding the problematic lookup. However, this action that's targeted to a specific bean doesn't feel like a perfect fit for the broader contract of a BeanPostProcessor. A callback that can be registered for a specific bean would be a better fit for our needs.

We'd like any callback that may be introduced to happen after bean post-processing. The crucial thing is that the callback is invoked before the bean can be used by application code. When I was trying to figure out what to do about the referenced Boot issue, a callback at around the point where AbstractBeanFactory.afterPrototypeCreation(String) or DefaultSingletonBeanRegistry.afterSingletonCreation(String) is called seemed to be a good fit. However, this is only based on a visual inspection of the code. I haven't verified that it would work as hoped.


Affects: 5.0.6

Reference URL: spring-projects/spring-boot#13042

2 votes, 8 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 10, 2018

Juergen Hoeller commented

I'm afraid I don't have the cycles left to properly sort this out for 5.1 RC1, so I'm putting this into the backlog for the time being. The introduction of such a specific callback is quite new territory... after all those years where the existing awareness and post-processing contracts remained largely untouched. I'd rather do a broader revision as a dedicated theme at a later point, assuming that there is a maybe-not-nice-but-effective workaround for the time being.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 11, 2018

Andy Wilkinson commented

The workaround appears to be effective and its use of BeanPostProcessor is an implementation detail so we're fine for Boot 2.1 and also well-placed to migrate to any new callback that Framework may introduce in the future.

@snicoll

This comment has been minimized.

Copy link
Member

@snicoll snicoll commented Jul 24, 2019

@jhoeller following the recent brainstorm we had on the subject, a bean created event for top-level singleton would help us solve several issues in Spring Boot. I am tentatively assigning this one to 5.2 RC2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.