We are looking for a way to binding properties to fluent
(possibly together with chain
style) style JavaConfig
method. For example:
public class FluentProperties {
private String name;
private int age;
public String name() {
return this.name;
}
public int age() {
return this.age;
}
public FluentProperties name(String name) {
this.name = name;
return this;
}
public FluentProperties age(int age) {
this.age = age;
return this;
}
}
In latest JavaBeanBinder
implementation, it only treat set
, get
and is
methods as binding properties, which means former FluentProperties
will not be bound properly. However, there are a lot of Builder
s nowadays written in this way. Even though we can implement a new configuration class but it would task a little time and meaningless.
After looking at the implementation of JavaBeanBinder
, I think one possible solution is make JavaBeanBinder
public or just make it possible to customize the properties after a configuration JavaBeanBinder.Bean
instance has been initialized.
Please have a look! Thanks a lot!
Comment From: philwebb
I'm not keen to make JavaBeanBinder
public since it's really intended to be a hidden implementation details of the Binder
. Even if it were public, there's currently no way of plugging in alternative DataObjectBinders
into the Binder
. This is an intentional decision as well since the Binder
is quite a complicated piece of code and we want to minimize the number of things that could go wrong with it.
Having said that, supporting fluent properties seems like a nice addition. We should look into what it will take to support them natively.
Comment From: snicoll
Reminder on the impact of configuration metadata and how we could figure out if the method refers to a property or not.
Comment From: cloorc
Reminder on the impact of configuration metadata and how we could figure out if the method refers to a property or not.
It is really somthing complicated. Could we just take a method which accept only one single parameter without suffix of set
, get
an or
into this consideration? Because we do not need to know whether it returns this
or just void
.
Comment From: philwebb
We discussed this on a team call today and ultimately decided that adding support for fluent builders isn't something we want to add. The fluent style is useful for developers to use, but isn't ideal for the binder. We'd generally recommend sticking with getters/setters or constructor arguments.
In your original comment you said "...there are a lot of Builders nowadays written in this way" which makes us think you are binding to third-party classes. Whilst this is supported, we found out ourselves that it often causes problems because you're no longer in complete control of the design of the @ConfigurationProperties
. Although it's more work, we've been moving more of our code to use @ConfigurationProperties
that we control and then mapping them onto the third-party code. If you're considering doing the same, take a look at the PropertyMapper
class which can help.