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/09/08 08:38:38 UTC
Re: Hierarchical registry for CamelContext
Hi,
I was thinking if instead we could have the camel context have its own
registry and end users can add their own "bean repository", like
context.addBeanRepository(new SpringBeanRepository())
context.addBeanRepository(new JNDIRepositoy())
Then when asking the registry to lookup beans, it will go through the
repositories according to their order and if it does not find any its
internal repositories which can then be used to add internal stuffs
like rest/service-call/etc configurations and so on.
Would that make sense ?
---
Luca Burgazzoli
On Mon, Feb 6, 2017 at 10:41 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah the idea of having it internal and named as containerRegistry, or
> maybe better named as contextRegistry or internalRegistry or
> camelInternalRegistry to make it stand out its not for Camel end users
> per see.
>
> A side bonus can be that we could make this internal registry
> available for unit testing Camel where users sometimes have a little
> trouble adding beans to the registry when using spring / cdi / java /
> karaf et all. There is a couple of JIRAs about this. Then the APIs on
> camel-test could offer a way to register custom beans that take
> priority over the regular registry.
>
>
>
>
>
>
> On Mon, Feb 6, 2017 at 10:13 AM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Well, what we have as today is just fine but sometime it requires a
>> little bit of additional work and maintenance even it is not strictly
>> needed.
>> Let's take as example hystrix and service call stuffs we added recently:
>>
>> 1. hystrix configuration is retrieved from the registry but work in
>> spring only as blueprint and cdi support is not implemented and would
>> require additional work, even the spring support is a little limited.
>> 2. service call configurations can be retrieved from the camel context
>> (via getter method) or from the registry but configurations you add to
>> the camel context element are added to the context, not the registry
>> so the behavior is a little different and it pollute the camel context
>> with additional methods.
>> 3. Add support for service-call to spring & co may require to write a
>> custom bean factory
>> 4. hystrix and service-call configurations are not supposed to be used
>> outside the camel context, so having them available for DI in
>> spring/blueprint/cdi does not make much sense
>>
>> The proposed solution aim to harmonize such things by adding them to a
>> camel contex own registry.
>> Of course the container specific registry can still be used to
>> configure hystrix/service-call and it is used first, something like:
>>
>> registry.lookupByName(String name, Class type) {
>> Object answer = containerRegistry.lookupByName(name);
>> if (answer == null) {
>> answer = contextRegistry,.lookupByName(name);
>> }
>>
>> return answer;
>> }
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale <pa...@gmail.com> wrote:
>>> Luca,
>>>
>>> Can you outline either some particular business problem that you're trying
>>> to solve or some current impediment to a solution that would be remedied by
>>> your proposed design change?
>>>
>>> Perhaps a few use case scenarios might help demonstrate the need. Just a
>>> thought.
>>>
>>> Thanks,
>>> Paul
>>>
>>> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli <lb...@gmail.com>
>>> wrote:
>>>
>>>> Yes an easy way to register beans that are not really meaningful
>>>> outside the camel context and maybe beans we do not want to make
>>>> available through dependency injection so they can't be easily
>>>> modified outside.
>>>> The hierarchical nature is only to make it transparent for consumer
>>>> i.e. a service call / hystrix implementation would search in the
>>>> registry and do not care were the bean come from.
>>>>
>>>> Indeed I'm not sure it is the best option, still need to experiment about
>>>> it.
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> > Hi
>>>> >
>>>> > So are you referring to some configuration for service call / hystrix
>>>> etc?
>>>> >
>>>> > The problem with the registry being hierarchical is that its backed by
>>>> > different implementations and then the user experience is different
>>>> > depending on which beans you get. For example CDI/spring has all kind
>>>> > of dependency injection magic, where as a basic map registry cannot do
>>>> > anything.
>>>> >
>>>> > So it sounds more like you are looking for an internal generic registry?
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Feb 2, 2017 at 6:21 PM, Luca Burgazzoli <lb...@gmail.com>
>>>> wrote:
>>>> >> Hello everyone,
>>>> >>
>>>> >> I'm wondering if it would make sense to have a sort of hierarchical
>>>> >> registry where the root registry is always created by the CamelContext
>>>> >> then the specific container registry adds its own registry on top and
>>>> >> the lookup would be top down.
>>>> >>
>>>> >> The motivation is that there are some beans that are only used by
>>>> >> camel and the registry is always involved so it does not make much
>>>> >> sense to have them available also on the container, i.e. the
>>>> >> ServiceCall and Hystrix configured through XML.
>>>> >>
>>>> >> This would reduce the complexity to add new definitions to the XML as
>>>> >> one do not need to create a container specific parser (blueprint,
>>>> >> spring, cdi) for object that are strictly camel-context related.
>>>> >>
>>>> >> What do you think ?
>>>> >>
>>>> >> ---
>>>> >> Luca Burgazzoli
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Claus Ibsen
>>>> > -----------------
>>>> > http://davsclaus.com @davsclaus
>>>> > Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Hierarchical registry for CamelContext
Posted by Luca Burgazzoli <lb...@gmail.com>.
Yeah this is for 3.0 :)
Posted so I won't forget
---
Luca Burgazzoli
On Fri, Sep 8, 2017 at 11:02 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Fri, Sep 8, 2017 at 10:38 AM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Hi,
>>
>> I was thinking if instead we could have the camel context have its own
>> registry and end users can add their own "bean repository", like
>>
>> context.addBeanRepository(new SpringBeanRepository())
>> context.addBeanRepository(new JNDIRepositoy())
>>
>> Then when asking the registry to lookup beans, it will go through the
>> repositories according to their order and if it does not find any its
>> internal repositories which can then be used to add internal stuffs
>> like rest/service-call/etc configurations and so on.
>>
>> Would that make sense ?
>>
>
> Maybe can we talk about this later.
> We have a 2.20.0 release to get done first.
>
>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Mon, Feb 6, 2017 at 10:41 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Yeah the idea of having it internal and named as containerRegistry, or
>>> maybe better named as contextRegistry or internalRegistry or
>>> camelInternalRegistry to make it stand out its not for Camel end users
>>> per see.
>>>
>>> A side bonus can be that we could make this internal registry
>>> available for unit testing Camel where users sometimes have a little
>>> trouble adding beans to the registry when using spring / cdi / java /
>>> karaf et all. There is a couple of JIRAs about this. Then the APIs on
>>> camel-test could offer a way to register custom beans that take
>>> priority over the regular registry.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Feb 6, 2017 at 10:13 AM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>>> Well, what we have as today is just fine but sometime it requires a
>>>> little bit of additional work and maintenance even it is not strictly
>>>> needed.
>>>> Let's take as example hystrix and service call stuffs we added recently:
>>>>
>>>> 1. hystrix configuration is retrieved from the registry but work in
>>>> spring only as blueprint and cdi support is not implemented and would
>>>> require additional work, even the spring support is a little limited.
>>>> 2. service call configurations can be retrieved from the camel context
>>>> (via getter method) or from the registry but configurations you add to
>>>> the camel context element are added to the context, not the registry
>>>> so the behavior is a little different and it pollute the camel context
>>>> with additional methods.
>>>> 3. Add support for service-call to spring & co may require to write a
>>>> custom bean factory
>>>> 4. hystrix and service-call configurations are not supposed to be used
>>>> outside the camel context, so having them available for DI in
>>>> spring/blueprint/cdi does not make much sense
>>>>
>>>> The proposed solution aim to harmonize such things by adding them to a
>>>> camel contex own registry.
>>>> Of course the container specific registry can still be used to
>>>> configure hystrix/service-call and it is used first, something like:
>>>>
>>>> registry.lookupByName(String name, Class type) {
>>>> Object answer = containerRegistry.lookupByName(name);
>>>> if (answer == null) {
>>>> answer = contextRegistry,.lookupByName(name);
>>>> }
>>>>
>>>> return answer;
>>>> }
>>>>
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale <pa...@gmail.com> wrote:
>>>>> Luca,
>>>>>
>>>>> Can you outline either some particular business problem that you're trying
>>>>> to solve or some current impediment to a solution that would be remedied by
>>>>> your proposed design change?
>>>>>
>>>>> Perhaps a few use case scenarios might help demonstrate the need. Just a
>>>>> thought.
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli <lb...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Yes an easy way to register beans that are not really meaningful
>>>>>> outside the camel context and maybe beans we do not want to make
>>>>>> available through dependency injection so they can't be easily
>>>>>> modified outside.
>>>>>> The hierarchical nature is only to make it transparent for consumer
>>>>>> i.e. a service call / hystrix implementation would search in the
>>>>>> registry and do not care were the bean come from.
>>>>>>
>>>>>> Indeed I'm not sure it is the best option, still need to experiment about
>>>>>> it.
>>>>>>
>>>>>> ---
>>>>>> Luca Burgazzoli
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> > Hi
>>>>>> >
>>>>>> > So are you referring to some configuration for service call / hystrix
>>>>>> etc?
>>>>>> >
>>>>>> > The problem with the registry being hierarchical is that its backed by
>>>>>> > different implementations and then the user experience is different
>>>>>> > depending on which beans you get. For example CDI/spring has all kind
>>>>>> > of dependency injection magic, where as a basic map registry cannot do
>>>>>> > anything.
>>>>>> >
>>>>>> > So it sounds more like you are looking for an internal generic registry?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Feb 2, 2017 at 6:21 PM, Luca Burgazzoli <lb...@gmail.com>
>>>>>> wrote:
>>>>>> >> Hello everyone,
>>>>>> >>
>>>>>> >> I'm wondering if it would make sense to have a sort of hierarchical
>>>>>> >> registry where the root registry is always created by the CamelContext
>>>>>> >> then the specific container registry adds its own registry on top and
>>>>>> >> the lookup would be top down.
>>>>>> >>
>>>>>> >> The motivation is that there are some beans that are only used by
>>>>>> >> camel and the registry is always involved so it does not make much
>>>>>> >> sense to have them available also on the container, i.e. the
>>>>>> >> ServiceCall and Hystrix configured through XML.
>>>>>> >>
>>>>>> >> This would reduce the complexity to add new definitions to the XML as
>>>>>> >> one do not need to create a container specific parser (blueprint,
>>>>>> >> spring, cdi) for object that are strictly camel-context related.
>>>>>> >>
>>>>>> >> What do you think ?
>>>>>> >>
>>>>>> >> ---
>>>>>> >> Luca Burgazzoli
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Claus Ibsen
>>>>>> > -----------------
>>>>>> > http://davsclaus.com @davsclaus
>>>>>> > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Hierarchical registry for CamelContext
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 8, 2017 at 10:38 AM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Hi,
>
> I was thinking if instead we could have the camel context have its own
> registry and end users can add their own "bean repository", like
>
> context.addBeanRepository(new SpringBeanRepository())
> context.addBeanRepository(new JNDIRepositoy())
>
> Then when asking the registry to lookup beans, it will go through the
> repositories according to their order and if it does not find any its
> internal repositories which can then be used to add internal stuffs
> like rest/service-call/etc configurations and so on.
>
> Would that make sense ?
>
Maybe can we talk about this later.
We have a 2.20.0 release to get done first.
>
> ---
> Luca Burgazzoli
>
>
> On Mon, Feb 6, 2017 at 10:41 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Yeah the idea of having it internal and named as containerRegistry, or
>> maybe better named as contextRegistry or internalRegistry or
>> camelInternalRegistry to make it stand out its not for Camel end users
>> per see.
>>
>> A side bonus can be that we could make this internal registry
>> available for unit testing Camel where users sometimes have a little
>> trouble adding beans to the registry when using spring / cdi / java /
>> karaf et all. There is a couple of JIRAs about this. Then the APIs on
>> camel-test could offer a way to register custom beans that take
>> priority over the regular registry.
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 6, 2017 at 10:13 AM, Luca Burgazzoli <lb...@gmail.com> wrote:
>>> Well, what we have as today is just fine but sometime it requires a
>>> little bit of additional work and maintenance even it is not strictly
>>> needed.
>>> Let's take as example hystrix and service call stuffs we added recently:
>>>
>>> 1. hystrix configuration is retrieved from the registry but work in
>>> spring only as blueprint and cdi support is not implemented and would
>>> require additional work, even the spring support is a little limited.
>>> 2. service call configurations can be retrieved from the camel context
>>> (via getter method) or from the registry but configurations you add to
>>> the camel context element are added to the context, not the registry
>>> so the behavior is a little different and it pollute the camel context
>>> with additional methods.
>>> 3. Add support for service-call to spring & co may require to write a
>>> custom bean factory
>>> 4. hystrix and service-call configurations are not supposed to be used
>>> outside the camel context, so having them available for DI in
>>> spring/blueprint/cdi does not make much sense
>>>
>>> The proposed solution aim to harmonize such things by adding them to a
>>> camel contex own registry.
>>> Of course the container specific registry can still be used to
>>> configure hystrix/service-call and it is used first, something like:
>>>
>>> registry.lookupByName(String name, Class type) {
>>> Object answer = containerRegistry.lookupByName(name);
>>> if (answer == null) {
>>> answer = contextRegistry,.lookupByName(name);
>>> }
>>>
>>> return answer;
>>> }
>>>
>>>
>>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale <pa...@gmail.com> wrote:
>>>> Luca,
>>>>
>>>> Can you outline either some particular business problem that you're trying
>>>> to solve or some current impediment to a solution that would be remedied by
>>>> your proposed design change?
>>>>
>>>> Perhaps a few use case scenarios might help demonstrate the need. Just a
>>>> thought.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli <lb...@gmail.com>
>>>> wrote:
>>>>
>>>>> Yes an easy way to register beans that are not really meaningful
>>>>> outside the camel context and maybe beans we do not want to make
>>>>> available through dependency injection so they can't be easily
>>>>> modified outside.
>>>>> The hierarchical nature is only to make it transparent for consumer
>>>>> i.e. a service call / hystrix implementation would search in the
>>>>> registry and do not care were the bean come from.
>>>>>
>>>>> Indeed I'm not sure it is the best option, still need to experiment about
>>>>> it.
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> > Hi
>>>>> >
>>>>> > So are you referring to some configuration for service call / hystrix
>>>>> etc?
>>>>> >
>>>>> > The problem with the registry being hierarchical is that its backed by
>>>>> > different implementations and then the user experience is different
>>>>> > depending on which beans you get. For example CDI/spring has all kind
>>>>> > of dependency injection magic, where as a basic map registry cannot do
>>>>> > anything.
>>>>> >
>>>>> > So it sounds more like you are looking for an internal generic registry?
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Feb 2, 2017 at 6:21 PM, Luca Burgazzoli <lb...@gmail.com>
>>>>> wrote:
>>>>> >> Hello everyone,
>>>>> >>
>>>>> >> I'm wondering if it would make sense to have a sort of hierarchical
>>>>> >> registry where the root registry is always created by the CamelContext
>>>>> >> then the specific container registry adds its own registry on top and
>>>>> >> the lookup would be top down.
>>>>> >>
>>>>> >> The motivation is that there are some beans that are only used by
>>>>> >> camel and the registry is always involved so it does not make much
>>>>> >> sense to have them available also on the container, i.e. the
>>>>> >> ServiceCall and Hystrix configured through XML.
>>>>> >>
>>>>> >> This would reduce the complexity to add new definitions to the XML as
>>>>> >> one do not need to create a container specific parser (blueprint,
>>>>> >> spring, cdi) for object that are strictly camel-context related.
>>>>> >>
>>>>> >> What do you think ?
>>>>> >>
>>>>> >> ---
>>>>> >> Luca Burgazzoli
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Claus Ibsen
>>>>> > -----------------
>>>>> > http://davsclaus.com @davsclaus
>>>>> > Camel in Action 2: https://www.manning.com/ibsen2
>>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2