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

Claus Ibsen updated CAMEL-20550:
--------------------------------
    Priority: Minor  (was: Major)

> Universal way to load resources
> -------------------------------
>
>                 Key: CAMEL-20550
>                 URL: https://issues.apache.org/jira/browse/CAMEL-20550
>             Project: Camel
>          Issue Type: Improvement
>    Affects Versions: 4.4.0
>            Reporter: Raymond
>            Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a 
> component uses a resourceURI then these resources can be loaded from 
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like 
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use 
> header
> 3. Some only allow resourceUri
> For example jsonata
> -------------------------------------------
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it 
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently 
> (now I use an external hosting for resource files as classpath/beans/file are 
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to