Re: Spring boot starter code generation
Hi Luca, On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli 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
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 wrote: > Hi Luca, > > On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli > 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
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 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 wrote: >> Hi Luca, >> >> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli >> 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
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 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 wrote: >> Hi Luca, >> >> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli >> 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
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 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 > 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 wrote: >>> Hi Luca, >>> >>> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli >>> 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
Hi Luca,
so.. I went for a jog, which got me thinking, perhaps it would be nice
to have ComponentConfigurer 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 {...}
or
class SecretsConfigurer implements ComponentConfigurer {...}
zoran
On Wed, May 17, 2017 at 12:45 PM, Zoran Regvart 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
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 wrote:
> Hi Luca,
> so.. I went for a jog, which got me thinking, perhaps it would be nice
> to have ComponentConfigurer 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 {...}
>
> or
>
> class SecretsConfigurer implements ComponentConfigurer {...}
>
> zoran
>
> On Wed, May 17, 2017 at 12:45 PM, Zoran Regvart 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
Great discussion :) On Thu, May 18, 2017 at 9:24 AM, Nicola Ferraro 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
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 wrote: > Great discussion :) > > On Thu, May 18, 2017 at 9:24 AM, Nicola Ferraro 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
