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 programmatic access to inner beans [SPR-8068] #12723

Closed
spring-projects-issues opened this issue Mar 20, 2011 · 6 comments
Closed

Provide programmatic access to inner beans [SPR-8068] #12723

spring-projects-issues opened this issue Mar 20, 2011 · 6 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Mar 20, 2011

Liu, Yinwei David opened SPR-8068 and commented

Is it possible to add a new API to allow user access inner bean in the context?

According to the javadoc of ApplicationContext.getBeansOfType(Class type), it won't return the nested beans, This method introspects top-level beans only. It does not check nested beans which might match the specified type as well.
Could you please let me know how we get nested bean from ApplicationContext?

e.g. we cannot get the bean b1 from application context by calling getBeansOfType.

<bean id="a1" class="class.A">
    <property name="b">
     <bean name="b1" class="class.B"/>
</property>
</bean> 

Affects: 3.0.5

Issue Links:

1 votes, 3 watchers

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

This is really by design. Typically when folks have wanted externalized access to nested beans, we tell them that's when they should declare it as top-level. Is there a reason this cannot work for you?

@spring-projects-issues
Copy link
Collaborator Author

Liu, Yinwei David commented

Hi Chris,
Thanks for your reply.
Normally, it will work. However, if we have an imported config by using import tag (it might be from 3rd library), and then we will not be able to get those nested beans in the imported config.

David

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

OK - as a use case it's probably comparatively rare. Given the impact that such a change would have, I'm hesitant to implement it. We can leave this issue open in a 'Waiting for Feedback' state just to see if additional votes and use cases show up.

@spring-projects-issues
Copy link
Collaborator Author

Liu, Yinwei David commented

I think people still can get the inner bean by using BeanPostProcessor. So, the new API should be a convenience to developers to get those inner beans when we need to know those inner beans.

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

Hi David,

I'm slating this for further review in 3.2 when we'll be taking care of a number of similar issues. In the meantime, I would suggest redefinition of the entire 3rd party bean definition locally in order to override it. At this point, you fully control the inner bean definition or can choose to make it top-level.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) and removed type: enhancement A general enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants