[ 
https://issues.apache.org/jira/browse/CAMEL-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072430#comment-13072430
 ] 

Keith Babo commented on CAMEL-4256:
-----------------------------------

I think this would be a great change on a number of fronts.  First, it would 
allow for a nice separation of the configuration info from the behavior of a 
component endpoint (e.g. Endpoint, Service, etc.).  Second, the fact that it's 
a JavaBean would mean that the mapping to XML would be relatively 
straightforward.  Perhaps through JAXB annotations or just using the default 
mapping rules in JAXB without annotations.  Finally, validation would go above 
and beyond what you could do with straight XML schema.  We have already gone 
down the route of defining separate XML schema for Camel endpoints, an exercise 
I would happily abandon if we could get this type of support up and running.

I went ahead and played around with a crude example using TimerEndpoint as an 
example.  My guess is the configuration bean would look something like the 
below.  Field-level annotations provide some basic support and the custom 
constraint @TimeDelayConstraint can be used to perform more advanced validation 
on the config object as a whole (in this case, verifying that 'time' and 
'delay' are not specified together).

{code:java}
@TimeDelayConstraint
public class TimerEndpointConfiguration implements EndpointConfiguration {

    private Date time;
    @Min(0)
    private long period = 1000;
    @Min(0)
    private long delay;
    private boolean fixedRate;
    private boolean daemon = true;
    private Timer timer;
    @NotNull
    private String timerName;
    
    public String getTimerName() {
        return timerName;
    }
    
    public void setTimerName(String timerName) {
        this.timerName = timerName;
    }

    // etc., etc.
}
{code}

If there's interest in moving this forward, I would love to help. :-)

> Adding a EndpointConfiguration interface
> ----------------------------------------
>
>                 Key: CAMEL-4256
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4256
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>    Affects Versions: 2.8.0
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 2.9.0, 3.0.0
>
>
> One of the key missing pieces from the API is the explicit concept of 
> EndpointConfiguration. We use URIs for that, ant that's great, but we don't 
> have it in the API. Some components do have an informal version though.
> I am proposing adding an EndpointConfiguration interface:
> {code}
> public interface EndpointConfiguration {
>   void fromUri(String uri);
>   String toUri();
> }
> {code}
> and maybe other methods, we could also use URI instead of string for 
> pre-parsing. Same as with other concepts the default implementation would be 
> in impl and components would extend that and add fields for configuration 
> parameters. 
> This would solve problems related to URI uniqueness to a good extent as 
> toUri() should always place parameters in the same order. The Endpoint 
> interface would change though.
> The main advantage would be that we can annotate parameters and use 
> javax.validation to specify if a field is @ProducerOnly, @ConsumerOnly for 
> example, which may exclude them from toUri() (yes, there are some impacts, 
> the id uri would be different than the config uric). We could annotate them 
> with @Secret to indicate that at least the value should not appear in clear 
> in the uri, etc. We could also add an @Default("value"), allowing us to 
> exclude from the uri fields set on the default value (even if the filed was 
> explicitly set) and so on.
> This would also make static validation possible unit testing configuration 
> would be vastly simplified and we could improve coverage. We can do it in an 
> incremental way without a big impact on existing components (especially 
> outside camel) via changes in DefaultEndpoint. I am working on a prototype, 
> but feedback is highly appreciated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to