activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: [Camel] simplified discovery of Component/Endpoints available
Date Wed, 04 Apr 2007 16:48:02 GMT
I like it.

But looking at DefaultCamelContext.resolveEndpoint() I think it can
lead to a little non determinism since 2 components could resolve the
same endpoint.  I'm thinking that to make things more deterministic,
uri should always start with the component name as the uri prefix.
That way we can look up the component out of a map instead of looping
though all of them to see if they can resolve the uri.

If the component has not been registered yet, we can then fall back
and auto create the component if by using the discovery techniques we
are used to using.

On 4/4/07, James Strachan <> wrote:
> I found the old implementation of EndpointResolver a bit smelly; so
> I've tried to clean it up to make it easier for folks to write new
> components.
> The basic idea is
> * folks should generally only need to write a Component & Endpoint
> implementation; no other classes needed other than maybe
> Producer/Consumer
> * components can create new endpoints via the resolveEndpoint(uri)
> method; the can just derive from DefaultComponent and get most of the
> URI magic for free; just overloading the actual factory method to
> create an Endpoint
> * adding a file in
> META-INF/services/org/apache/came/component/${scheme} can plugin
> auto-discovered components
> * users can explicitly instantiate, configure & register components to
> the CamelContext; or via the Injector the CamelContext can auto-inject
> them with their required dependencies. (e.g. folks could have a single
> DataSource or ConnectionFactory in a spring context which could be
> auto-injected etc)
> I've written a little bit of documentation for component developers here...
> I've just committed the above changes. Thoughts?
> --
> James
> -------



View raw message