[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825957#comment-17825957
]
Raymond commented on CAMEL-20550:
---------------------------------
Yes, I had an inkling that this would be the outcome. I wanted to give some
feedback anyway, with the points I'm struggling with.
I do have a somewhat different vision on the use of beans. In my idea "beans"
are an anti-pattern in message-orientated middleware. This middleware is about
messages (like xml/json). Sure, Camel has a strong foot in the Java world, and
because it's Java based it tries to make maximum advantage of that. Beans
however hide flow logic and can cause side effects. I'll try to make Camel as
easy available to non-Java programmers, working with YAML or XML, but beans
don't help with that. Just my opinion.
And yes, I also use the resourceHelper to load strings into components or with
routeLoader, but rather want to avoid this step and use a more direct approach.
I may try to create a generic ResourceToVariable processor/bean and see how
that goes.
> 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)
