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 Builders 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.