Skip to content

Conversation

@alebar
Copy link
Contributor

@alebar alebar commented Nov 1, 2016

Frankly: I'm not sure what exactly is happening here, but I guess that if we're depending on singletons registered in the factory then we should stick to singletons - not beans.

This PR resolves this issue: #7270

I hope this helps,
Alek

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 1, 2016
@wilkinsona wilkinsona added status: on-hold We can't start working on this issue yet and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 22, 2016
@wilkinsona
Copy link
Member

Thanks for the PR, @alebar. I'm labelling this as on hold until we figure out the best way to fix this. Please see my comments on #7270 for some more details.

@philwebb philwebb added this to the 1.4.3 milestone Nov 23, 2016
@wilkinsona wilkinsona removed the status: on-hold We can't start working on this issue yet label Nov 25, 2016
wilkinsona added a commit that referenced this pull request Nov 25, 2016
* gh-7271:
  Test that a broken factory bean does not break resetting of mocks
  Prevent a broken factory bean from breaking the resetting of mocks
wilkinsona added a commit that referenced this pull request Feb 1, 2023
An unwanted side-effect of the changes made in c6bdd13 to fix
gh-7271 is that a mock produced by a factory bean is not reset. To
allow such a mock to be reset without regressing the fix we now call
getBean(…) as we did before c6bdd13, however the call is now
performed in a defensive manner falling back to getSingleton(…) when
it fails.

Closes gh-33830
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants