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
