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/disabl
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
s
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 h
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
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 g
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
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 *ComponentConfig
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.e
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 any
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
10 matches
Mail list logo
