camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Gredler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-6552) More dynamic options for properties component locations
Date Tue, 16 Jul 2013 13:52:48 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Gredler updated CAMEL-6552:
----------------------------------

    Description: 
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}}.

  was:
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}}s 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}}.

    
> 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

Mime
View raw message