Closed hohwille closed 9 years ago
Feel free to "move" this issue to spring core as I am a user of spring boot and can not tell the exact place for this easily. Maybe both worlds are involved...
The problem is that we have to enumerate all the property values for all the @ConfigurationProperties
that we bind - because of the relaxed binding we never know until the last moment whether a given property is needed to bind to any given bean. 34 is probably (some multiple of) the number of @ConfigurationProperties
beans in your context. We can have a look at an optimization I guess (contributions more than welcome).
@hohwille do you have a sample application that you can share that shows the problem?
@philwebb it's trivial. Just put a breakpoint in AbstractEnvironment.getProperty()
and see how many times it hits it even for the same property key.
I tried that with the JPA sample but without much luck, perhaps because it's using the embedded database?
Maybe. But I see it with any app that has @ConfigurationProperties
(so nearly everything). I think the changes in #3402 maybe fix things so we don't ask for properties that we know aren't going to match. In my simple test app it reduced the number of times I resolved one property from 9 down to 1.
@dsyer :+1: We will test this with 1.3.0.RC1 as soon as it is out and give feedback. Then we can upgrade to 1.3.0.RELEASE whenever this will come out and everyone is happy. Thanks for taking care. Spring rocks!
As discussed in #1312 and https://github.com/ulisesbocchio/jasypt-spring-boot/issues/7 spring boot is resolving the property
spring.datasource.password
34 times in a simple vanilla app with JPA via hibernate. My expectation is that spring boot creates a data source and resolves this property ONCE to callsetPassword
on that datasource.