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 <[EMAIL PROTECTED]> 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...
http://cwiki.apache.org/CAMEL/writing-components.html
I've just committed the above changes. Thoughts?
--
James
-------
http://radio.weblogs.com/0112098/
--
Regards,
Hiram
Blog: http://hiramchirino.com
