On Wed, Mar 23, 2016 at 3:55 PM, lb <[email protected]> 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 proxy.xxx 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 ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
