camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james strachan (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CAMEL-1386) create a way of loading all of the available components & languages on startup - so that they can be exposed for tooling/reporting
Date Fri, 24 May 2013 09:44:23 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

james strachan resolved CAMEL-1386.
-----------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: Future)
                   2.12.0

This seems fixed at least for the non-osgi case with the findComponentNames() MBean method
on the Camel context
                
> 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/jira/browse/CAMEL-1386
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: james strachan
>            Priority: Minor
>             Fix For: 2.12.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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message