[
https://issues.apache.org/activemq/browse/CAMEL-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50005#action_50005
]
James Strachan commented on CAMEL-1386:
---------------------------------------
Agreed with all of that Gert yes.
I guess what I'm saying is - we should try to eagerly load the component and
language instances and register them with the CamelContext so we can query for
the available Component / Language instances that are available for use.
So with spring we can do this on startup - finding all beans in the
applicationContext which implement Component/Language - and by eagerly loading
the files from the classpath for stuff not configured in spring (like we do for
converters).
I agree - for OSGi this would need to be a bundle listener to add/remove
components/languages dynamically
> 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.
