[
https://issues.apache.org/jira/browse/CAMEL-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303400#comment-14303400
]
Claus Ibsen commented on CAMEL-7419:
------------------------------------
There is more on the table
The verbose configuration of endpoints, is better suited in the <endpoint>
configuration, eg such as
https://github.com/apache/camel/blob/master/components/camel-spring/src/test/resources/org/apache/camel/spring/endpointReference.xml#L32
Then we can allow to do
{code}
<endpoint id="foo" uri="file:something">
<property name="includes" value="backup/*.xml"/>
<property name="recursive" value="true"/>
...
</endpoint>
And then in the routes you refer to the endpoint from its id, which keeps it
tidy and lean
{code}
<from uri="ref:foo"/>
...
{code}
Now the other things that is on the table is that eg Camel 2.15 would allow us
to generate per component type safe XSD schema, so we could do
{code}
<from>
<file directory="somewhere" includes="backup/*.xml" recursive="true"/>
</from>
Though it would require a fair bit of work to get the generation correct, and
also configuring "repeatable/dynamic" options can maybe become too verbose? eg
such as on the http endpoint we have httpClient.XXX where XXX maps to a option
on the http client library, that Camel do not know about at compile time, but
is mapped at runtime.
And btw an xml attribute is valid with a new line, for example all the top of
the xml files uses that in the namespace mapping such as:
https://github.com/apache/camel/blob/master/components/camel-spring/src/test/resources/org/apache/camel/spring/endpointReference.xml#L20
But having the functionality to use <property> in the <endpoint> is something
that I think we can do in the 2.x timeline.
> Configure endpoints with many options in the DSL using a mix of url and
> properties
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-7419
> URL: https://issues.apache.org/jira/browse/CAMEL-7419
> Project: Camel
> Issue Type: New Feature
> Components: camel-blueprint, camel-core, camel-spring
> Reporter: Claus Ibsen
> Fix For: 3.0.0
>
>
> See nabble
> http://camel.465427.n5.nabble.com/longish-uri-on-file-endpoint-tp5750862.html
> We could toy with the idea of allowing to configure endpoints using a mix of
> uri's and properties. So you can define the uri in a more readable manner if
> it has many options.
> {code}
> <from uri="ftp:someserver">
> <property name="delete" value="true"/>
> <property name="username" value="{{ftpUser}}"/>
> <property name="password" value="Se!@rec"/>
> ... // more properties here
> </from>
> {code}
> This should also be supported in the <endpoint>, eg
> {code}
> <endpoint id="myFtp" uri="ftp:/xxxx">
> <property name="delete" value="true"/>
> <property name="username" value="{{ftpUser}}"/>
> <property name="password" value="Se!@rec"/>
> </endpoint>
> {code}
> We could also support breaking (a bit wacky idea) up the url's in multiple
> properties url2, url3, url4, which get's appended as one combined url by
> Camel internally. This allows people to breakup options that may belong
> together in a few url's. We may come up with a better name than url2, url3
> etc.
> {code}
> <from uri="ftp:someserver">
> <property name="url2" value=".... more options here"/>
> <property name="url3" value=".... more options here"/>
> </from>
> {code}
> Also we can support the p:xxx attribute syntax so you can do shorthand
> property assignment. We do this with the property placeholder in the EIPs.
> (see Using property placeholders for any kind of attribute in the XML DSL at
> http://camel.apache.org/using-propertyplaceholder.html). Then it becomes just
> one tag.
> {code}
> <from uri="ftp:someserver"
> p:delete="true"
> p:username="{{ftpUser}}"
> p:password="Se!@rec"/>
> {code}
> Although using the <from><property> is similar to what you do in
> spring/blueprint and also tooling friendly. So you can have code assistance
> in your IDE, and XML schema validation.
> Also it allows for people to configure their passwords without using RAW()
> style. As the value is used as-is.
> And for Java DSL, we can have some java builder to do similar. But people can
> also just break up their strings, or use string format etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
