On Fri, Sep 8, 2017 at 10:38 AM, Luca Burgazzoli <lburgazz...@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.ib...@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 <lburgazz...@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.g...@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 <lburgazz...@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.ib...@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 <lburgazz...@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
