Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
Description
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
/META-INF/services/org/apache/camel/component/*
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 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
/META-INF/services/org/apache/camel/component/jms
but generically we can't auto-discover all the component names. So maybe we also generate a little file
/META-INF/services/org/apache/camel/componentName
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.
Attachments
Issue Links
- depends upon
-
CAMEL-1385 allow the (transitive) maven dependencies on a module to be displayed in the runtime when we fail to load a component/language/converter
- Closed