[
https://issues.apache.org/activemq/browse/CAMEL-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50004#action_50004
]
Gert Vanthienen commented on CAMEL-1386:
----------------------------------------
Do you mean like keeping a ComponentRegistry of some kind to lookup the
component by name instead of doing the lookup with the META-INF file when
reading it from the endpoint URI?
I think filling the registry might be somewhat different, depending on the
runtime environment:
- For a plain Java environment, scanning the classpath for a file like you
suggested would be nice way to handle it
- When using Spring, we could also take a look at the ApplicationContext for
finding other Compent implementations and registering them
- For an OSGi environment, it would be nice to build a BundleListener/Activator
to add components to the registry as soon as the bundle is started.
> create a way of loading all of the available components & languages on
> startup - so that they can be exposed for tooling/reporting
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-1386
> URL: https://issues.apache.org/activemq/browse/CAMEL-1386
> Project: Apache Camel
> Issue Type: Improvement
> Reporter: James Strachan
> Fix For: 2.1.0
>
>
> There's no way to know what languages or components are available (other than
> looking at all objects in the registry but lots of components/languages are
> never in the registry) - we only know the ones that have been registered
> (used).
> This is because we dynamically create them on the fly by looking up the
> /META-INF/services/.../$name file. The downside is I don't think we can list
> - say - the files in
> {code}/META-INF/services/org/apache/camel/component/*{code} on the classpath
> - due to the ClassLoader API; you can only look up resources by name.
> It might be nice to load them all on startup so we can iterate through them
> all - so from a tooling/UI perspective we can list them all.
> For example in the [Web Console|http://camel.apache.org/] we can then show
> all the available components folks can use if they wish and similarly
> languages.
> To implement this we could maybe hack the maven plugin we mention in
> CAMEL-1385 (which we'll start using in each camel module which defines a
> component/language/converter) so that we generate some canonical file which
> links to the component/language.
> e.g. for JMS we might already have this file on the classpath
> {code}
> /META-INF/services/org/apache/camel/component/jms
> {code}
> but generically we can't auto-discover all the component names. So maybe we
> also generate a little file
> {code}
> /META-INF/services/org/apache/camel/componentName
> {code}
> which just contains the component name (i.e. 'jms').
> Then we can load all of the available
> */META-INF/services/org/apache/camel/componentName* files - read their
> contents and then load the "jms" component along with all the other ones we
> find.
> Ditto for languages too. We don't have this problem for type converters as we
> already load those on startup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
