I'm not sure if there is a more elegant way to deal with it. If this proposal can be adopted, I hope you can give me more advice I can confirm that the following problems exist <bean name="${bean.name:product}" class="icu.funkye.entity.Product"></bean> bean name=${bean.name:product} Instead of product or bean.name=xxxx

I would like to be able to support placeholder resolution beanname

fixes #27224

Comment From: bclozel

Thanks for contributing - just so you're aware, issues that have not been assigned to a milestone or at least confirmed by a team member can be marked as invalid for many reasons. We're happy to get your help but we'd rather avoid wasting your time if the PR is not merged. As a side note, we tend to accept PRs that contribute tests.

Comment From: funky-eyes

Thanks for contributing - just so you're aware, issues that have not been assigned to a milestone or at least confirmed by a team member can be marked as invalid for many reasons. We're happy to get your help but we'd rather avoid wasting your time if the PR is not merged. As a side note, we tend to accept PRs that contribute tests.

Thank you for your patience, and I'll fill in the test cases later to aid in code review

Comment From: funky-eyes

Thanks for contributing - just so you're aware, issues that have not been assigned to a milestone or at least confirmed by a team member can be marked as invalid for many reasons. We're happy to get your help but we'd rather avoid wasting your time if the PR is not merged. As a side note, we tend to accept PRs that contribute tests.

@bclozel I've supplemented the test cases

Comment From: snicoll

Thanks for the PR but we can't really bring this consistently given how early the name of the bean play a central role in the bean creation lifecycle.

Placeholders get resolved in an early pass at the bean definition level, once only, with the results stored in the actual runtime bean definition. Expressions on the other hand get resolved as late as possible, at bean instantiation time, and re-resolved for every bean instance (in case of a non-singleton).

Given that the bean name is the key to the bean definition, we won't be able to provide that support. And providing it for XML-based contexts doesn't feel right.