The approach is awesome. Today a user that needs a custom (programmatic)
component configuration has to define a new @Bean, losing the benefits of
property-based configuration, or use a post processor.
The first way is the one I see more, probably because it's easier.
With configurers, one would have the configuration magic and whatever we
will add in the future also on custom bean. Actually people will not need
to create custom component beans.
I wonder (before this goes too far and we add more stuff) if we should add
a easy way to disable a configurer (also a configurer defined by Camel).
Nicola
On Thu, May 18, 2017 at 1:03 AM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi Luca,
> so.. I went for a jog, which got me thinking, perhaps it would be nice
> to have ComponentConfigurer<T extends Component> interface in
> camel-core and have this usable in non Spring applications and applied
> to component by the generic type parameter.
>
> In other words, I could have:
>
> class ProxyComponentConfigurer implements
> ComponentConfigurer<BaseHttpComponent> {...}
>
> or
>
> class SecretsConfigurer implements ComponentConfigurer<WithSecrets> {...}
>
> zoran
>
> On Wed, May 17, 2017 at 12:45 PM, Zoran Regvart <zo...@regvart.com> wrote:
> >
> > One use case I can think of is to have a *ComponentConfigurer that
> > configures custom TLS properties to multiple components or configures
> > username/passwords. Might be far fetched but it's a possibility that
> > opens up with this approach. Somewhat same can be done with
> > BeanDefinitionRegistryPostProcessor approach but it would be more
> > complex IMHO,
>
>
>
>
> --
> Zoran Regvart
>
