On 2 September 2013 21:52, Tom Ellis <telli...@gmail.com> wrote:
> Hi All,
>
> I asked this on stackoverflow [1] and didn't get a response, but this
> is obviously a better spot to get questions answered.
>
> Consider the following:
>
> public class MyRouteBuilder extends RouteBuilder {
>
> @Override
> public void configure() throws Exception {
> FileEndpoint dropLocation = new FileEndpoint();
> dropLocation.setCamelContext(getContext());
> dropLocation.setFile(new File("/data"));
> dropLocation.setRecursive(true);
> dropLocation.setPreMove(".polled");
> dropLocation.setNoop(true);
> dropLocation.setMaxMessagesPerPoll(1);
>
> from(dropLocation).to(...
>
> versus
>
> public class MyBuilder extends RouteBuilder {
>
> @Override
> public void configure() throws Exception {
>
> from("file://data?recursive=true&preMove=.polled&noop=true&maxMessagesPerPoll=1").to(...
>
> Programmatically I get code completion and the like, whereas with the
> URI everything is in a single line.
Agreed. Using many parameters soon gets messy with the URI. Plus bean
properties works much nicer with dependency injection frameworks &
IDEs.
So unless its just 1 parameter; I prefer the Java API to URIs really.
> I've noticed that the JMX beans
> also don't seem to build the URI for stuff like hawt.io if you build
> the endpoint with the programmatic way as well. What are the other
> pros/cons for each?
I think this is down to many endpoints not being able to auto-create
the URI string on the endpoint property so its probably not exposed in
JMX.
Though we could maybe fix that; since we now know - for many endpoints
now - which properties are URI parameters due to the use of @UriParam,
we could generate the URI string dynamically based on the property
values if folks have configured the endpoint as a bean, rather than
from a URI string?
https://cwiki.apache.org/confluence/display/CAMEL/Endpoint+Annotations
> Pretty much all the examples I see utilise the URI method - is this
> the preferred way?
It is often easier for many simple URIs; but either approach is valid really.
> Could it be possible to use the builder pattern or something to build
> up an endpoint, e.g.
>
> FileEndpoint dropLocation = new
> FileEndpoint.Builder().camelContext(getContext()).file(new
> File("/data")).recursive().preMove().noop().maxMessagesPerPoll(1).build();
another option is to use both :)
FileEndpoint dropLocation = endpoint("file://data", FileEndpoint.class);
// now configure extra properties...
On the builder front; I wonder if we could use a tool like JAnnocessor
- or hack some APT processing tool or something - to automatically
create builder friendly APIs to endpoints annotated with @UriParam?
Then we'd get an automatically generated nice builder API? i.e. add
builder style methods to the endpoint classes (which already have
getter and setters - but add a builder like method facade above the
setters)?
e.g. if we code generated methods like this at build time:
public class FileEndpoint {
// these are code generated at APT compile time...
public FileEndpoint recursive() {
setRecursive(true);
return this;
}
....
}
then the code could be like this...
from(endpoint("file://data",
FileEndpoint.class).recursive().preMove().noop().maxMessagesPerPoll(1)).
to(endpoint("activemq:foo",
ActiveMQEndpoint.class).transactional().concurrentConsumers(5))
and have the URI strings generated for the above for tooling & JMX?
--
James
-------
Red Hat
Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
