On Thu, Mar 24, 2016 at 1:34 PM, Claus Ibsen <[email protected]> wrote: > 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. >
I forgot to mention that also Proxy need to be annotated :-) > 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. > Yep I agree that maps and beans are advanced configuration options and should be avoided but there are cases where they make sense so I think it is worth having native support in camel at least to make it a common path so tooling & co may try to handle them properly. > 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. > Here the goal was to provide a option validation and yes an enum would be better but sometimes not possible or not making much sense so imho having a way to validate the options is valuable. > > > >> 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. > I will
