camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gert Vanthienen (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:39:59 GMT


Gert Vanthienen commented on CAMEL-1386:

Do you mean like keeping a ComponentRegistry of some kind to lookup the component by name
instead of doing the lookup with the META-INF file when reading it from the endpoint URI?

I think filling the registry might be somewhat different, depending on the runtime environment:
- For a plain Java environment, scanning the classpath for a file like you suggested would
be nice way to handle it
- When using Spring, we could also take a look at the ApplicationContext for finding other
Compent implementations and registering them
- For an OSGi environment, it would be nice to build a BundleListener/Activator to add components
to the registry as soon as the bundle is started. 

> 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