camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <>
Subject [jira] Commented: (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 Thu, 26 Feb 2009 09:57:59 GMT


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

> 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:
>             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|] 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.

View raw message