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.
