You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Luca Burgazzoli <lb...@gmail.com> on 2017/05/16 16:23:20 UTC
Spring boot starter code generation
Hello,
as today the camel-package-maven-plugin is responsible to generate
component starters so it generates the properties configuration class
as well of the auto configuration one which is good but there may be
some cases in which one may want to further tweak the bean creation
process, i.e. for stuffs like ehcache/infinispan/hazelcast I'd like to
find out if we can integrate with spring caching so you can configure
the cache the spring way and reuse it in camel.
What would be the best option to keep the auto generation awesomeness
and at the same time have a way to tweak the process ?
---
Luca Burgazzoli
Re: Spring boot starter code generation
Posted by Luca Burgazzoli <lb...@gmail.com>.
Yes that is the idea so users and developers can hook into the auto
configuration process without impacting the code generation
awesomeness.
Will raise a JIRA.
---
Luca Burgazzoli
On Wed, May 17, 2017 at 12:50 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Is the idea to still run the maven plugin to auto generate the spring
> boot starter skeleton code, and then be able to write addition source
> code for extra stuff?
>
> If so I would suggest to use separate packages so the auto generated
> code and the manual code are separated.
>
> But yeah good idea for such a functionality as the more we learn and
> use spring boot the more we can make it more awesome.
>
>
>
> On Wed, May 17, 2017 at 12:29 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Yeah that's something I was thinking about but then I ended up with
>> testing something different, do not know if it is the best way :)
>>
>> So the camel-package-maven-plugin would generate:
>>
>> - org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration
>> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration
>> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer
>> - org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer
>>
>> Then EhcacheComponentAutoConfiguration applies all the configurer
>> (type EhcacheComponentConfigurer) it can found to the EhcacheComponent
>> it is setting up and there will be at least one that is the
>> DefaultConfigurer that simply apply the properties from
>> EhcacheComponentConfiguration. The advantage of this method is that we
>> can use standard spring annotation to include/exclude configurer
>> without having to manually write all the conditions.
>>
>> I've created a simple example here:
>> https://github.com/lburgazzoli/camel-ehcache-starter
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart <zo...@regvart.com> wrote:
>>> Hi Luca,
>>>
>>> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> What would be the best option to keep the auto generation awesomeness
>>>> and at the same time have a way to tweak the process ?
>>>
>>> BeanDefinitionRegistryPostProcessor can remove and add bean
>>> definitions, so you can do pretty much anything you need.
>>>
>>> So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to
>>> perform additional post processing of the bean definition registry,
>>> then have this BeanDefinitionRegistryPostProcessor and SPI interface
>>> in camel-spring-boot, and the implementation of the SPI in the
>>> component starter. The SPI implementation can be loaded using
>>> FactoryFinder.
>>>
>>> zoran
>>> --
>>> Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Spring boot starter code generation
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Is the idea to still run the maven plugin to auto generate the spring
boot starter skeleton code, and then be able to write addition source
code for extra stuff?
If so I would suggest to use separate packages so the auto generated
code and the manual code are separated.
But yeah good idea for such a functionality as the more we learn and
use spring boot the more we can make it more awesome.
On Wed, May 17, 2017 at 12:29 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Yeah that's something I was thinking about but then I ended up with
> testing something different, do not know if it is the best way :)
>
> So the camel-package-maven-plugin would generate:
>
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer
> - org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer
>
> Then EhcacheComponentAutoConfiguration applies all the configurer
> (type EhcacheComponentConfigurer) it can found to the EhcacheComponent
> it is setting up and there will be at least one that is the
> DefaultConfigurer that simply apply the properties from
> EhcacheComponentConfiguration. The advantage of this method is that we
> can use standard spring annotation to include/exclude configurer
> without having to manually write all the conditions.
>
> I've created a simple example here:
> https://github.com/lburgazzoli/camel-ehcache-starter
>
> ---
> Luca Burgazzoli
>
>
> On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart <zo...@regvart.com> wrote:
>> Hi Luca,
>>
>> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> What would be the best option to keep the auto generation awesomeness
>>> and at the same time have a way to tweak the process ?
>>
>> BeanDefinitionRegistryPostProcessor can remove and add bean
>> definitions, so you can do pretty much anything you need.
>>
>> So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to
>> perform additional post processing of the bean definition registry,
>> then have this BeanDefinitionRegistryPostProcessor and SPI interface
>> in camel-spring-boot, and the implementation of the SPI in the
>> component starter. The SPI implementation can be loaded using
>> FactoryFinder.
>>
>> zoran
>> --
>> Zoran Regvart
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Spring boot starter code generation
Posted by Luca Burgazzoli <lb...@gmail.com>.
The configurer I'm working on as today are only supposed to
post-process our spring-boot auto magics so there's not side effects
for a end user but yes it could be extended later on to any
component/language/dataformat in the registry.
And yes I'm also taking into account an option to enable/disable
configurer on different level (always in spring boot), i.e. disable
all configurer for a component/language/dataformat or just disable a
single one.
Let me see what we can have and how it works in this first round then
we can discuss the next steps.
---
Luca Burgazzoli
On Thu, May 18, 2017 at 9:31 AM, Zoran Regvart <zo...@regvart.com> wrote:
> Great discussion :)
>
> On Thu, May 18, 2017 at 9:24 AM, Nicola Ferraro <ni...@gmail.com> wrote:
>> 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).
>
> I think that if this is all at configuration time (before component
> starts), then you have an option to opt-out by not including the
> configurer on the classpath and to provide your own configurer that
> rollbacks prevous configurer's changes; so perhaps just something like
> Ordered interface in Spring?
>
> zoran
> --
> Zoran Regvart
Re: Spring boot starter code generation
Posted by Zoran Regvart <zo...@regvart.com>.
Great discussion :)
On Thu, May 18, 2017 at 9:24 AM, Nicola Ferraro <ni...@gmail.com> wrote:
> 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).
I think that if this is all at configuration time (before component
starts), then you have an option to opt-out by not including the
configurer on the classpath and to provide your own configurer that
rollbacks prevous configurer's changes; so perhaps just something like
Ordered interface in Spring?
zoran
--
Zoran Regvart
Re: Spring boot starter code generation
Posted by Nicola Ferraro <ni...@gmail.com>.
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
>
Re: Spring boot starter code generation
Posted by Zoran Regvart <zo...@regvart.com>.
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
Re: Spring boot starter code generation
Posted by Zoran Regvart <zo...@regvart.com>.
Hi Luca,
I think this approach with EhcacheComponentConfigurer is really nice,
it allows you to also have additional jars on classpath, separate form
the -starter jars, to perform additional configuration, that could
prove be very flexible.
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
On Wed, May 17, 2017 at 12:29 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Yeah that's something I was thinking about but then I ended up with
> testing something different, do not know if it is the best way :)
>
> So the camel-package-maven-plugin would generate:
>
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration
> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer
> - org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer
>
> Then EhcacheComponentAutoConfiguration applies all the configurer
> (type EhcacheComponentConfigurer) it can found to the EhcacheComponent
> it is setting up and there will be at least one that is the
> DefaultConfigurer that simply apply the properties from
> EhcacheComponentConfiguration. The advantage of this method is that we
> can use standard spring annotation to include/exclude configurer
> without having to manually write all the conditions.
>
> I've created a simple example here:
> https://github.com/lburgazzoli/camel-ehcache-starter
>
> ---
> Luca Burgazzoli
>
>
> On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart <zo...@regvart.com> wrote:
>> Hi Luca,
>>
>> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> What would be the best option to keep the auto generation awesomeness
>>> and at the same time have a way to tweak the process ?
>>
>> BeanDefinitionRegistryPostProcessor can remove and add bean
>> definitions, so you can do pretty much anything you need.
>>
>> So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to
>> perform additional post processing of the bean definition registry,
>> then have this BeanDefinitionRegistryPostProcessor and SPI interface
>> in camel-spring-boot, and the implementation of the SPI in the
>> component starter. The SPI implementation can be loaded using
>> FactoryFinder.
>>
>> zoran
>> --
>> Zoran Regvart
--
Zoran Regvart
Re: Spring boot starter code generation
Posted by Luca Burgazzoli <lb...@gmail.com>.
Yeah that's something I was thinking about but then I ended up with
testing something different, do not know if it is the best way :)
So the camel-package-maven-plugin would generate:
- org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration
- org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration
- org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer
- org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer
Then EhcacheComponentAutoConfiguration applies all the configurer
(type EhcacheComponentConfigurer) it can found to the EhcacheComponent
it is setting up and there will be at least one that is the
DefaultConfigurer that simply apply the properties from
EhcacheComponentConfiguration. The advantage of this method is that we
can use standard spring annotation to include/exclude configurer
without having to manually write all the conditions.
I've created a simple example here:
https://github.com/lburgazzoli/camel-ehcache-starter
---
Luca Burgazzoli
On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart <zo...@regvart.com> wrote:
> Hi Luca,
>
> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> What would be the best option to keep the auto generation awesomeness
>> and at the same time have a way to tweak the process ?
>
> BeanDefinitionRegistryPostProcessor can remove and add bean
> definitions, so you can do pretty much anything you need.
>
> So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to
> perform additional post processing of the bean definition registry,
> then have this BeanDefinitionRegistryPostProcessor and SPI interface
> in camel-spring-boot, and the implementation of the SPI in the
> component starter. The SPI implementation can be loaded using
> FactoryFinder.
>
> zoran
> --
> Zoran Regvart
Re: Spring boot starter code generation
Posted by Zoran Regvart <zo...@regvart.com>.
Hi Luca,
On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> What would be the best option to keep the auto generation awesomeness
> and at the same time have a way to tweak the process ?
BeanDefinitionRegistryPostProcessor can remove and add bean
definitions, so you can do pretty much anything you need.
So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to
perform additional post processing of the bean definition registry,
then have this BeanDefinitionRegistryPostProcessor and SPI interface
in camel-spring-boot, and the implementation of the SPI in the
component starter. The SPI implementation can be loaded using
FactoryFinder.
zoran
--
Zoran Regvart