camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gert Vanthienen (JIRA)" <j...@apache.org>
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

    [ https://issues.apache.org/activemq/browse/CAMEL-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50004#action_50004
] 

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


Mime
View raw message