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

Support SpEL in bean class names [SPR-12817] #17414

Closed
spring-issuemaster opened this issue Mar 14, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Mar 14, 2015

Gary Russell opened SPR-12817 and commented

This (using a property placeholder for a class) works...

<util:properties id="props">
	<prop key="fooClass">java.lang.String</prop>
</util:properties>

<context:property-placeholder properties-ref="props"/>

<bean id="containerClass" class="${fooClass}">
	<constructor-arg value="#{'class is ' + props.fooClass}" />
</bean>

...but this does not...

<util:properties id="props">
	<prop key="fooClass">java.lang.String</prop>
</util:properties>

<bean id="containerClass" class="#{props.fooClass}">
	<constructor-arg value="#{'class is ' + props.fooClass}" />
</bean>

...ClassNotFoundException: #{props.fooClass}

It would be useful if it was possible to use SpEL as an alternative to a PPH to determine a bean class.


Issue Links:

  • INT-3677 JMS: Support Properties/SpEL in container-class

Referenced from: commits 768f6e8

1 votes, 4 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 16, 2015

Juergen Hoeller commented

This is a quite non-trivial change since bean classes play a central role in the bean creation lifecycle, with quite a few things getting validated against the resolved Class from early on... Nevertheless, it's doable with a bit of extra checking in the right places, and will be available in the upcoming 4.2 snapshot.

Note that I wouldn't necessarily recommend this approach for plain property resolution since there is still a key difference: 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).

That said, the feature is actually quite nice for more complex computation: e.g. referring to another bean's class, or dynamically building the class name based on arbitrary runtime context.

Juergen

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