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 <claus.ib...@gmail.com> wrote:
> 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
