Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMpNYoYAjS=VgcAra-v03r1RCt+1cK1_eZuijEgT=tVeY4BaXA@mail.gmail.com>
References: <CAMpNYoabsARZPODmCRYW9gO_yeV2Y-8-MKP=3SvY8gUSDeaCMA@mail.gmail.com>
 <CAGB5yN=CqneJzoJCo0Wi1sd2=Be+j79YyKhvZTP6E4msTTeL1Q@mail.gmail.com>
 <CAMpNYoZVARrj+COw90rJSSfLf5pUeuUDeCMLrjU_vF3eTSw32w@mail.gmail.com>
 <CAJ5znhv-2=Tt=2eyp0J2crNf8q+1fKaVQayYYgZZnTsakLgZ+g@mail.gmail.com>
 <CAMpNYoaXTKM_8ZQSDnWU4+hHW5gn9fvxzn2uqmNLUH-fVZhuCg@mail.gmail.com>
 <CAGB5yNkLzmr=QhBCOX9u=-X16pGaWkLUZ+vY7Jf_JRrudbzh_Q@mail.gmail.com> <CAMpNYoYAjS=VgcAra-v03r1RCt+1cK1_eZuijEgT=tVeY4BaXA@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Fri, 8 Sep 2017 11:02:44 +0200
Message-ID: <CAGB5yN=hs3wbpTOrtPixH1iEnz0EpuZrbDkmjEsj5Nn9LB53YQ@mail.gmail.com>
Subject: Re: Hierarchical registry for CamelContext
To: dev <dev@camel.apache.org>
Content-Type: text/plain; charset="UTF-8"
archived-at: Fri, 08 Sep 2017 09:03:13 -0000

On Fri, Sep 8, 2017 at 10:38 AM, Luca Burgazzoli <lburgazzoli@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 <claus.ibsen@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 <lburgazzoli@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 <paul.n.gale@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 <lburgazzoli@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 <claus.ibsen@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 <lburgazzoli@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