[
https://issues.apache.org/jira/browse/CAMEL-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13714019#comment-13714019
]
Daniel Gredler commented on CAMEL-6552:
---------------------------------------
Yep, part of the purpose is to allow decentralized modules to configure not
only routes, but also route configuration (from properties files).
The other goal is to allow property file location resolution behavior to be
customized. For example, our application uses a custom "classpath or
filesystem" resource resolution method in other parts of the code, where
resources can be either in the filesystem or on the classpath, with filesystem
resources taking precedence. With something like the {{PropertiesLocation}}
interface, we could provide a custom implementation that finds all
{{/my/application/**/integration.properties}} files, without requiring the
modules to register each file location independently, and without requiring
central configuration of all file locations.
The current patch doesn't expect users to call {{addLocation(...)}} directly
(although they can if they want to). The {{addLocation(...)}} method is used
internally when {{PropertiesLocation}} instances are found in the registry --
it's a sort of implicit location addition, just like {{RouteBuilders}} are
automatically picked up and used to add routes to the Camel context.
You're correct that the clashing of property names is something that you need
to be careful about -- but that's also that status quo when dealing with
multiple properties files.
The idea of allowing {{RouteBuilder}} instances to have their own properties
locations is interesting. What would that look like? An extra collection of
properties locations on each {{RouteBuilder}}, and then when initializing
routes in the route builder, use a custom clone of the global
{{PropertiesComponent}} with the extra locally-scoped locations?
> More dynamic options for properties component locations
> -------------------------------------------------------
>
> Key: CAMEL-6552
> URL: https://issues.apache.org/jira/browse/CAMEL-6552
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.11.0
> Reporter: Daniel Gredler
> Priority: Minor
> Attachments: dynamic-properties-location.patch
>
>
> As part of the properties component, Camel provides abstractions that make it
> easy for third parties to customize its behavior (e.g. {{PropertiesParser}},
> {{PropertiesResolver}}). However, the resolution of properties file locations
> cannot be customized, and file locations cannot be dynamically resolved at
> runtime.
> Additionally, Camel's Spring integration allows {{RouteBuilder}} instances to
> dynamically contribute new routes to the Camel context. However, it is not
> easy to dynamically contribute new properties file locations containing
> configuration for these routes. The result is that while routes can be
> contributed dynamically in a decentralized way, route configuration must be
> centralized.
> The attached patch implements one possible solution to this limitation. It
> adds a new interface ({{PropertiesLocation}}), a default implementation
> ({{DefaultPropertiesLocation}}), and two new methods on the
> {{PropertiesComponent}}: {{setLocation(PropertiesLocation)}} and
> {{addLocation(PropertiesLocation)}}. It also ensures that any
> {{PropertiesLocation}} instances available in the registry (or Spring
> context) are automatically added to the {{PropertiesComponent}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
