camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Improve endpoint configuration
Date Thu, 24 Mar 2016 12:34:25 GMT
On Wed, Mar 23, 2016 at 3:55 PM, lb <> wrote:
> Hi,
> I've been working on a number of components in the lates months and what I found
> a little bit repetitive is to handle endpoints configuration so I would like to
> know if there is any interest about improving such area by adding
> support as example
> for:
> - collections
> - nested objects
> - validation
> - default values
> As today a common pattern to configure an endpoint is:
>     @Override
>     protected Endpoint createEndpoint(
>         String uri, String remaining, Map<String, Object> parameters)
> throws Exception {
>         MyConfiguration configuration = new MyConfiguration();
>         setProperties(configuration, parameters);
>         return new MyEndpoint(uri, this, configuration);
>     }
> As far as I know, setProperties does not take into account field annotations so
> handling i.e. multi value objects (lists, maps) has to be manually
> done or default
> values have to be defined on both the annotations and the fields.
> So let's suppose to have a configuration bean like:
>     @UriParams
>     class MyConfiguration {
>         @UriPath
>         @Metadata(required = "true")
>         private String key;
>         @UriPath( defaultValue = "localhost" )
>         private String host;
>         @UriPath( elementType = User.class)
>         private List<User> users;
>         @UriPath( elementType = User.class )
>         private Map<String, User> aliases;
>         @UriPath( elementType = User.class )
>         private Proxy proxy;
>         @UriPath( elementType = String.class, enum = "NEW, UPDATE, DELETE")
>         private List<String> events;
>         // getter/setters as usual
>     }
> I'd like to be able to write an endpint uri like:
>     "users=#usr1,#usr2&aliases.alias1=#usr1&proxy.userName=myUsr,proxy.password=myPwd&events=NEW,CANCEL"

We should avoid the notation when possible and only use it
for more advanced use cases. There is no type safety and the end user
and tooling do not know what setters are possible to use.

So its better to have a proxyUserName / proxyPassword as options in
the configuration class so its nicely exposed as options.

Also its not so common to have Map types with nested type objects. eg
going down that path makes configuring harder. Instead the endpoint
should provide a easier to use configuration.

And for enums, then if the type is an enum, then its out of the box.
In your use case the type is String. So it can be any kind of string.
Having enums in the annotation makes the component doc / schema aware
of those and can make it easier for tooling where you can have a
dropdown to chose among the enum values.

> And having camel to automatically bind/validate my options using annotations so:
> - set defaults, in this case set host to "localhost" as indicated by
> the annotation
> - split users, lookup values in the registry and fill users
> - set key/vaue for aliases
> - set bean properties to proxy (of course proxy need to be instantiable)
> - warn about unknown value (CACNEL) for events
> - warn/fail as required field key is not provided

Yes all good suggestions but I think its more a goal for Camel 3.0
than for 2.x. See further below.

> This enhancement is definitively not intended to replace any of the methods
> available as now bur to leverage them and make configurations simpler
> and a little
> more annotation oriented.
> If there is any interest I'd more than happy to work on it.

The @UriParam et all was added much after how components is done
today. They are a means for component documentation and tooling. Only
recently we have @UriParams on all the options.

And in the future we can make that mandatory so components and
endpoints are always documented and we know what options there are and
what they do etc.

So in the future it may make feasible to use the @UriParam annotations
as a means for validation and configuring as well.

However I think we need to get the component docs and the other parts
done before we go down this road. I suggest to take a look at after
Camel 2.18, eg for Camel 3.0. There we can move to make using
@UriParam mandatory. And figure out in camel-core how component and
endpoint creation logic can tap into those annotations and do
accordingly to your ideas.

But I think its worth creating a JIRA and refer to this @dev and mark
it for 3.0.

> Regards,
> Luca

Claus Ibsen
----------------- @davsclaus
Camel in Action 2:

View raw message