We've got a few properties classes (like RepositoryRestProperties) that have an applyTo method. If we manage to move to interface based properties this logic should do elsewhere.
Comment From: snicoll
@philwebb I am not sure I am following. IMO, that's ok to have that logic there and not everything has to be interface-based unless I am missing something.
Comment From: philwebb
Yeah, the interface thing is a bit of red herring. What I meant to say was, I'm not sure if coupling a @ConfigurationProperties class directly to other classes is a good idea. I'm wondering if we should just keep configuration classes as simple as possible and put that mapping code elsewhere?
Comment From: wilkinsona
I'm in favour of separating things. Keeping applyTo-style logic in configuration properties classes has bitten us in the past. For example, I'm pretty sure it has contributed to the problem described in #11112.
Comment From: snicoll
@philwebb Can we tighten or clarify the scope of this issue? I can see several places where having straightforward mapping logic is not an obvious problem. Does this issue relates to method that take an object to map things only? For instance, would this method be affected by this issue?
Comment From: philwebb
@snicoll I'd say that method should be refactored (but I'm not sure where it should end up living).
Comment From: EduColnago
Hi! i would like to tackle this one. is it ok?
Comment From: snicoll
@EduColnago thanks for the offer but we're not quite sure ourselves what pattern we're going to use for this. Please watch the ideal-for-contribution label.