[
https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103213#comment-15103213
]
Jyrki Ruuskanen commented on CAMEL-9498:
----------------------------------------
If we really want to solve this for everybody in one go, the most
straightforward solution is to add {monospaced}public SimpleRegistry
getLocalRegistry();{monospaced} to a CamelContext (sub)interface. To achieve
this we just have to:
# Make sure CompositeRegistry handles nesting correctly.
# Let every implementation of this (possibly new) CamelContext interface own a
local registry of type SimpleRegistry. getLocalRegistry() just returns this
registry.
# If a registry is given in the CamelContext constructor, CamelContext's
registry will be a CompositeRegistry with its localRegistry and the given
registry. Otherwise, registry = localRegistry.
Since access to the CamelContext is pretty much ubiquitous, above changes would
solve the add/override problem for tests and everywhere else, too.
What do you think?
> Always provide a writable local registry
> ----------------------------------------
>
> Key: CAMEL-9498
> URL: https://issues.apache.org/jira/browse/CAMEL-9498
> Project: Camel
> Issue Type: Improvement
> Components: camel-scr
> Reporter: Jyrki Ruuskanen
> Priority: Minor
>
> Many Camel components need to reference objects in CamelContext's registry as
> part of their configuration (for example httpClientConfigurer for http/http4
> and restletRealm for restlet).
> These objects often apply to that particular CamelContext and not others,
> thus the registry holding these bits could be local. Using a local registry
> prevents the risk of conflicting keys and spares us from devising a naming
> policy for even trivial stuff.
> To conveniently create and add these objects, even inside RouteBuilder's
> configure method, we need write access to said registry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
