Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1930338798.1235641199386.JavaMail.jira@brutus>
Date: Thu, 26 Feb 2009 01:39:59 -0800 (PST)
From: "Gert Vanthienen (JIRA)" <jira@apache.org>
To: camel-dev@activemq.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
In-Reply-To: <1527220651.1235638919854.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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