[
https://issues.apache.org/jira/browse/CAMEL-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101656#comment-15101656
]
Jyrki Ruuskanen commented on CAMEL-9498:
----------------------------------------
Thanks for taking a look at this case.
Please note that I'm not changing the way Camel works here. AbstractCamelRunner
is just a helper class for the users of camel-scr. The beauty of having a local
registry always available as in the PR is that we can run the exact same
concrete camel runner both with or without OSGi (plain JUnit).
If using a composite registry is not OK in this case the other alternative is
to let camel-scr users pick the type of registry for themselves. Similar needs
have come up in CamelTestSupport, if I recall correctly. Let me know if I must
change the approach.
In a more general note, I firmly believe that having a local registry for stuff
that is only interesting locally makes sense. It makes sure whatever you do
with the registry it won't have any effect outside the intended scope.
> 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)
