You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Guillaume Nodet <gn...@apache.org> on 2019/06/05 21:23:00 UTC
[HEADS UP] The endpoint-dsl branch
I just pushed a branch called "endpoint-dsl".
My goal is to experiment with an auto-generated DSL for endpoints, mainly
to have a complete and type-safe java DSL for endpoints instead of using
URI containing all the parameters. Right now, it compiles but isn't really
usable at a DSL.
I'll get back as soon as I have something which can actually be used so
that we can discuss further various options.
My rough goal is to be able to write something like:
from(file("target/data/foo").delay(4000).backoffMultiplier(4
).backoffIdleThreshold(2).backoffErrorThreshold(3))
.to(mock("result"))
instead of
from(
"file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
)
.to("mock:result")
Stay tuned !
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
Le jeu. 6 juin 2019 à 12:21, Pasquale Congiusti <
pasquale.congiusti@gmail.com> a écrit :
> Hey Guillame,
> recently I was looking at something similar on component side in order to
> make an integration archetype. I was thinking to use the annotations on the
> endpoint (@UriEndpoint, @UriPath, @UriParam) in order to scan which are the
> available parameters, and, from there onward being able to map the
> available options of such components. I guess you can scan those at runtime
> and being even able to make a fluent builder fully automated.
>
Yes, that's what I'm doing to generate the fluent builders. I'm also using
the generated meta-model (the json files) but it's lacking some stuff to
produce correct java code, I do use both the model and reflection on the
classes.
>
> Let me know how if you need any further info to develop such idea.
>
> Cheers,
> Pasquale.
>
> On Thu, Jun 6, 2019 at 12:01 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > I've just pushed a working test case:
> >
> >
> >
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
> >
> > It's missing the generation of the dsl methods for each endpoint
> consumer /
> > producer (see
> >
> >
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69
> > )
> > but I'm not sure yet where/how to nicely plug them in the DSL.
> >
> > Ideas and feedback welcome !
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints,
> mainly
> > > to have a complete and type-safe java DSL for endpoints instead of
> using
> > > URI containing all the parameters. Right now, it compiles but isn't
> > really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > >
> >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah we have also talked about a fluent builder for setting component options.
But 1st goal is all the endpoints.
On Thu, Jun 6, 2019 at 12:21 PM Pasquale Congiusti
<pa...@gmail.com> wrote:
>
> Hey Guillame,
> recently I was looking at something similar on component side in order to
> make an integration archetype. I was thinking to use the annotations on the
> endpoint (@UriEndpoint, @UriPath, @UriParam) in order to scan which are the
> available parameters, and, from there onward being able to map the
> available options of such components. I guess you can scan those at runtime
> and being even able to make a fluent builder fully automated.
>
> Let me know how if you need any further info to develop such idea.
>
> Cheers,
> Pasquale.
>
> On Thu, Jun 6, 2019 at 12:01 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > I've just pushed a working test case:
> >
> >
> > https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
> >
> > It's missing the generation of the dsl methods for each endpoint consumer /
> > producer (see
> >
> > https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69
> > )
> > but I'm not sure yet where/how to nicely plug them in the DSL.
> >
> > Ideas and feedback welcome !
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > > to have a complete and type-safe java DSL for endpoints instead of using
> > > URI containing all the parameters. Right now, it compiles but isn't
> > really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > >
> > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] The endpoint-dsl branch
Posted by Pasquale Congiusti <pa...@gmail.com>.
Hey Guillame,
recently I was looking at something similar on component side in order to
make an integration archetype. I was thinking to use the annotations on the
endpoint (@UriEndpoint, @UriPath, @UriParam) in order to scan which are the
available parameters, and, from there onward being able to map the
available options of such components. I guess you can scan those at runtime
and being even able to make a fluent builder fully automated.
Let me know how if you need any further info to develop such idea.
Cheers,
Pasquale.
On Thu, Jun 6, 2019 at 12:01 PM Guillaume Nodet <gn...@apache.org> wrote:
> I've just pushed a working test case:
>
>
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
>
> It's missing the generation of the dsl methods for each endpoint consumer /
> producer (see
>
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69
> )
> but I'm not sure yet where/how to nicely plug them in the DSL.
>
> Ideas and feedback welcome !
>
>
> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
>
> > I just pushed a branch called "endpoint-dsl".
> >
> > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > to have a complete and type-safe java DSL for endpoints instead of using
> > URI containing all the parameters. Right now, it compiles but isn't
> really
> > usable at a DSL.
> > I'll get back as soon as I have something which can actually be used so
> > that we can discuss further various options.
> > My rough goal is to be able to write something like:
> >
> > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > .to(mock("result"))
> >
> > instead of
> >
> > from(
> >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > )
> > .to("mock:result")
> >
> > Stay tuned !
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [HEADS UP] The endpoint-dsl branch
Posted by Luca Burgazzoli <lb...@gmail.com>.
Looks cool.
Would it make sense to have also an EndpointRouteBuilder class so
EndpointBuilder is automatically inherit ?
---
Luca Burgazzoli
On Fri, Jun 7, 2019 at 10:16 AM Guillaume Nodet <gn...@apache.org> wrote:
> So I just pushed a few changes to be able to actually integrate the
> endpoint DSL in the existing DSL easily.
> In order to leverage it, you need to inherit the EndpointBuilder interface
> somehow, then you have access to methods named fromXxx and toXxx for each
> endpoint.
> The test case has been refactored and now looks like:
>
>
> from(fromFile("target/data/files/").initialDelay(0).delay(10).fileName(constant("report.txt")).delete(true).charset("UTF-8"))
> .convertBodyTo(String.class)
> .to(toMock("result"));
>
>
>
> https://github.com/apache/camel/blob/c2dd5c80a82ad982127105f9ae5afde674bbe214/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L60-L62
>
> Any suggestions ?
>
>
> Le jeu. 6 juin 2019 à 12:01, Guillaume Nodet <gn...@apache.org> a écrit :
>
> > I've just pushed a working test case:
> >
> >
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
> >
> > It's missing the generation of the dsl methods for each endpoint consumer
> > / producer (see
> >
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69
> )
> > but I'm not sure yet where/how to nicely plug them in the DSL.
> >
> > Ideas and feedback welcome !
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> écrit :
> >
> >> I just pushed a branch called "endpoint-dsl".
> >>
> >> My goal is to experiment with an auto-generated DSL for endpoints,
> mainly
> >> to have a complete and type-safe java DSL for endpoints instead of using
> >> URI containing all the parameters. Right now, it compiles but isn't
> really
> >> usable at a DSL.
> >> I'll get back as soon as I have something which can actually be used so
> >> that we can discuss further various options.
> >> My rough goal is to be able to write something like:
> >>
> >> from(file("target/data/foo").delay(4000).backoffMultiplier(4
> >> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> >> .to(mock("result"))
> >>
> >> instead of
> >>
> >> from(
> >>
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> >> )
> >> .to("mock:result")
> >>
> >> Stay tuned !
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >>
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
So I just pushed a few changes to be able to actually integrate the
endpoint DSL in the existing DSL easily.
In order to leverage it, you need to inherit the EndpointBuilder interface
somehow, then you have access to methods named fromXxx and toXxx for each
endpoint.
The test case has been refactored and now looks like:
from(fromFile("target/data/files/").initialDelay(0).delay(10).fileName(constant("report.txt")).delete(true).charset("UTF-8"))
.convertBodyTo(String.class)
.to(toMock("result"));
https://github.com/apache/camel/blob/c2dd5c80a82ad982127105f9ae5afde674bbe214/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L60-L62
Any suggestions ?
Le jeu. 6 juin 2019 à 12:01, Guillaume Nodet <gn...@apache.org> a écrit :
> I've just pushed a working test case:
>
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
>
> It's missing the generation of the dsl methods for each endpoint consumer
> / producer (see
> https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69)
> but I'm not sure yet where/how to nicely plug them in the DSL.
>
> Ideas and feedback welcome !
>
>
> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
>
>> I just pushed a branch called "endpoint-dsl".
>>
>> My goal is to experiment with an auto-generated DSL for endpoints, mainly
>> to have a complete and type-safe java DSL for endpoints instead of using
>> URI containing all the parameters. Right now, it compiles but isn't really
>> usable at a DSL.
>> I'll get back as soon as I have something which can actually be used so
>> that we can discuss further various options.
>> My rough goal is to be able to write something like:
>>
>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
>> .to(mock("result"))
>>
>> instead of
>>
>> from(
>> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
>> )
>> .to("mock:result")
>>
>> Stay tuned !
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
I've just pushed a working test case:
https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L57-L59
It's missing the generation of the dsl methods for each endpoint consumer /
producer (see
https://github.com/apache/camel/blob/bcaa3ce64d9f1a5fd2ee9fcb154c7a2682c9979e/core/camel-core/src/test/java/org/apache/camel/component/file/FileConsumeCharsetTest.java#L64-L69)
but I'm not sure yet where/how to nicely plug them in the DSL.
Ideas and feedback welcome !
Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
> I just pushed a branch called "endpoint-dsl".
>
> My goal is to experiment with an auto-generated DSL for endpoints, mainly
> to have a complete and type-safe java DSL for endpoints instead of using
> URI containing all the parameters. Right now, it compiles but isn't really
> usable at a DSL.
> I'll get back as soon as I have something which can actually be used so
> that we can discuss further various options.
> My rough goal is to be able to write something like:
>
> from(file("target/data/foo").delay(4000).backoffMultiplier(4
> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> .to(mock("result"))
>
> instead of
>
> from(
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> )
> .to("mock:result")
>
> Stay tuned !
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 12 juin 2019 à 07:32, Claus Ibsen <cl...@gmail.com> a écrit :
> Hi
>
> Also another idea could be to add a bit of javadoc to the fromXXX and
> toXXX methods as they are the starting point, where we can add the
> description of the component, so users can better see what it does.
> And in the future when we have a new website with a more stable url,
> we can add hyperlink to the component doc page.
>
> Also I would like to see if we can include the "group" for each of
> these options in the javadoc as a way of categorising what the option
> is used for, eg common, security, scheduler.
>
Right, good ideas.
> Also if not implemented yet, then we should mark the methods as
> @Deprecated if they are listed so in the json schema metadata.
>
> That one is done, though not really tested because we removed all
the deprecated stuff in 3.0 branch.
>
>
>
> On Wed, Jun 12, 2019 at 7:27 AM Claus Ibsen <cl...@gmail.com> wrote:
> >
> > Hi
> >
> > Great work so far - love it.
> >
> > One little thing is that all endpoints inherit some options from the
> > default endpoint which are seldom used. Maybe we could move these into
> > an abstract base class, so they are not on the same "level" as all the
> > other options, eg
> >
> > basicPropertyBinding
> > synchronous
> > bridgeErrorHandler
> > exceptionHandler
> > exchangePattern
> > lazyStartProducer
> >
> >
> > For example IDEA code completion would should parent methods in its
> > list with a different colour than regular methods (bold).
> >
> > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> > >
> > > I think I'm done with a first usable pass at the endpoint DSL.
> > > I've removed the getters/setters, added 2 flavors of fluent methods
> (one
> > > with the real java type, another one with a String to allow references
> and
> > > property placeholder processing), renamed the generated classes to
> > > XxxEndpointBuilder and cleaned things a bit.
> > > In order to access this API, one would create an EndpointRouteBuilder
> > > anonymous class instead of the usual RouteBuilder (see below). The
> only
> > > difference is that it gives immediate access to the fromXxx() and
> toXxx()
> > > methods that are generated as default methods on the interface, so
> there's
> > > no need to import anything else.
> > > Please have a look and let me know what you think or if we see
> anything to
> > > improve.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > return new EndpointRouteBuilder() {
> > > @Override
> > > public void configure() throws Exception {
> > > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > > "/${file:name}"))
> > > .to(toMock("result"));
> > > }
> > > };
> > > }
> > >
> > >
> > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> écrit :
> > >
> > > > I just pushed a branch called "endpoint-dsl".
> > > >
> > > > My goal is to experiment with an auto-generated DSL for endpoints,
> mainly
> > > > to have a complete and type-safe java DSL for endpoints instead of
> using
> > > > URI containing all the parameters. Right now, it compiles but isn't
> really
> > > > usable at a DSL.
> > > > I'll get back as soon as I have something which can actually be used
> so
> > > > that we can discuss further various options.
> > > > My rough goal is to be able to write something like:
> > > >
> > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > .to(mock("result"))
> > > >
> > > > instead of
> > > >
> > > > from(
> > > >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > )
> > > > .to("mock:result")
> > > >
> > > > Stay tuned !
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Also another idea could be to add a bit of javadoc to the fromXXX and
toXXX methods as they are the starting point, where we can add the
description of the component, so users can better see what it does.
And in the future when we have a new website with a more stable url,
we can add hyperlink to the component doc page.
Also I would like to see if we can include the "group" for each of
these options in the javadoc as a way of categorising what the option
is used for, eg common, security, scheduler.
Also if not implemented yet, then we should mark the methods as
@Deprecated if they are listed so in the json schema metadata.
On Wed, Jun 12, 2019 at 7:27 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> Great work so far - love it.
>
> One little thing is that all endpoints inherit some options from the
> default endpoint which are seldom used. Maybe we could move these into
> an abstract base class, so they are not on the same "level" as all the
> other options, eg
>
> basicPropertyBinding
> synchronous
> bridgeErrorHandler
> exceptionHandler
> exchangePattern
> lazyStartProducer
>
>
> For example IDEA code completion would should parent methods in its
> list with a different colour than regular methods (bold).
>
> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > I think I'm done with a first usable pass at the endpoint DSL.
> > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > with the real java type, another one with a String to allow references and
> > property placeholder processing), renamed the generated classes to
> > XxxEndpointBuilder and cleaned things a bit.
> > In order to access this API, one would create an EndpointRouteBuilder
> > anonymous class instead of the usual RouteBuilder (see below). The only
> > difference is that it gives immediate access to the fromXxx() and toXxx()
> > methods that are generated as default methods on the interface, so there's
> > no need to import anything else.
> > Please have a look and let me know what you think or if we see anything to
> > improve.
> >
> > Cheers,
> > Guillaume
> >
> > protected RouteBuilder createRouteBuilder() throws Exception {
> > return new EndpointRouteBuilder() {
> > @Override
> > public void configure() throws Exception {
> > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > "/${file:name}"))
> > .to(toMock("result"));
> > }
> > };
> > }
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > > to have a complete and type-safe java DSL for endpoints instead of using
> > > URI containing all the parameters. Right now, it compiles but isn't really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 12 juin 2019 à 07:27, Claus Ibsen <cl...@gmail.com> a écrit :
> Hi
>
> Great work so far - love it.
>
> One little thing is that all endpoints inherit some options from the
> default endpoint which are seldom used. Maybe we could move these into
> an abstract base class, so they are not on the same "level" as all the
> other options, eg
>
> basicPropertyBinding
> synchronous
> bridgeErrorHandler
> exceptionHandler
> exchangePattern
> lazyStartProducer
>
>
> For example IDEA code completion would should parent methods in its
> list with a different colour than regular methods (bold).
>
Yeah, I can try to keep the endpoint class hierarchy somehow.
We have the DefaultEndpoint which defines the one you mentioned, but
we also have the ScheduledPollEndpoint which defines a bunch of
parameters (startScheduler, initialDelay, delay, timeUnit, useFixedDelay...)
Let me give it a try...
Guillaume
>
> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > I think I'm done with a first usable pass at the endpoint DSL.
> > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > with the real java type, another one with a String to allow references
> and
> > property placeholder processing), renamed the generated classes to
> > XxxEndpointBuilder and cleaned things a bit.
> > In order to access this API, one would create an EndpointRouteBuilder
> > anonymous class instead of the usual RouteBuilder (see below). The only
> > difference is that it gives immediate access to the fromXxx() and toXxx()
> > methods that are generated as default methods on the interface, so
> there's
> > no need to import anything else.
> > Please have a look and let me know what you think or if we see anything
> to
> > improve.
> >
> > Cheers,
> > Guillaume
> >
> > protected RouteBuilder createRouteBuilder() throws Exception {
> > return new EndpointRouteBuilder() {
> > @Override
> > public void configure() throws Exception {
> > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > "/${file:name}"))
> > .to(toMock("result"));
> > }
> > };
> > }
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints,
> mainly
> > > to have a complete and type-safe java DSL for endpoints instead of
> using
> > > URI containing all the parameters. Right now, it compiles but isn't
> really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Great work so far - love it.
One little thing is that all endpoints inherit some options from the
default endpoint which are seldom used. Maybe we could move these into
an abstract base class, so they are not on the same "level" as all the
other options, eg
basicPropertyBinding
synchronous
bridgeErrorHandler
exceptionHandler
exchangePattern
lazyStartProducer
For example IDEA code completion would should parent methods in its
list with a different colour than regular methods (bold).
On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> I think I'm done with a first usable pass at the endpoint DSL.
> I've removed the getters/setters, added 2 flavors of fluent methods (one
> with the real java type, another one with a String to allow references and
> property placeholder processing), renamed the generated classes to
> XxxEndpointBuilder and cleaned things a bit.
> In order to access this API, one would create an EndpointRouteBuilder
> anonymous class instead of the usual RouteBuilder (see below). The only
> difference is that it gives immediate access to the fromXxx() and toXxx()
> methods that are generated as default methods on the interface, so there's
> no need to import anything else.
> Please have a look and let me know what you think or if we see anything to
> improve.
>
> Cheers,
> Guillaume
>
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new EndpointRouteBuilder() {
> @Override
> public void configure() throws Exception {
> from(fromFile(start).initialDelay(0).delay(10).move(done +
> "/${file:name}"))
> .to(toMock("result"));
> }
> };
> }
>
>
> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
>
> > I just pushed a branch called "endpoint-dsl".
> >
> > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > to have a complete and type-safe java DSL for endpoints instead of using
> > URI containing all the parameters. Right now, it compiles but isn't really
> > usable at a DSL.
> > I'll get back as soon as I have something which can actually be used so
> > that we can discuss further various options.
> > My rough goal is to be able to write something like:
> >
> > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > .to(mock("result"))
> >
> > instead of
> >
> > from(
> > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > )
> > .to("mock:result")
> >
> > Stay tuned !
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] The endpoint-dsl branch
Posted by Onder SEZGIN <on...@apache.org>.
that's an awesome amount of work by looking the implementation in
camel-package-maven-plugin and its result of autogenerating the dsl.
i am going excited to see the enhancements in xml dsl in a similar regard.
thanks Guillaume
On Wed, Jun 12, 2019 at 11:38 PM Guillaume Nodet <gn...@apache.org> wrote:
> So I pushed my latest changes, which include the work discussed here.
> I really like it better, for both having a single method for both
> consumers/producers (while still having separate interfaces when the
> options are specific to the consumer/producer), and having a separate set
> of interfaces for advanced options, so that the choice when completing is
> minimized.
> Let me know what you think...
> The file endpoint builder DSL is available at
>
> https://github.com/apache/camel/blob/endpoint-dsl/core/camel-core/src/main/java/org/apache/camel/model/endpoint/FileEndpointBuilderFactory.java
>
> Le mer. 12 juin 2019 à 19:17, Guillaume Nodet <gn...@apache.org> a écrit
> :
>
> > A compiling prototype is available at
> > https://gist.github.com/gnodet/ad5e00ec8e6855bbdab3d6f58d8ced80
> >
> > However, this can't be combined with Claus' suggestion to keep some kind
> > of hierarchy between the builders.
> >
> > Though we could make the properties flagged with the "advanced" label
> > accessible using the advanced() / basic() methods in the below example.
> > https://gist.github.com/gnodet/aa393baada9c0819cfcba01d7261b943
> >
> > So at the end, the choice is between
> >
> > - two methods fromFile() / toFile() and the ability to make options in
> > a hierarchy
> > - a single method file() for both consumers / producers with the
> > ability to group advanced options in a separate interface to split
> them a
> > bit from the basic options
> >
> > I would tend to favour the second option, as I think the benefit of
> moving
> > the advanced properties apart is greater than the ability to have them
> in a
> > hierarchy.
> >
> > Cheers,
> > Guillaume
> >
> > Le mer. 12 juin 2019 à 17:15, Guillaume Nodet <gn...@apache.org> a
> > écrit :
> >
> >> I'll experiment a bit, but your suggestion looks promising.
> >>
> >> Le mer. 12 juin 2019 à 15:24, Jan Bednář <pu...@janbednar.eu> a écrit
> :
> >>
> >>> Hi all, one idea, how to keep clean file() instead fromFile() and
> >>> toFile(). I have not checked full code of source branch, so apologize,
> >>> if this is not possible to integrate for some reason.
> >>>
> >>> I think it is not needed to know if you are consumer or producer when
> >>> creating builder. It can be switched to consumer/producer builder
> >>> afterwards, when consumer/producer specific builder method is used.
> >>>
> >>> There could be two interfaces FileEndpointConsumerBuilder and
> >>> FileEndpointProducerBuilder. Consumer builder interface holds common
> and
> >>> consumer-only options. Producer builder interface holds common and
> >>> producer-only options. Builder class implements
> >>> FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
> >>> methods returns builder self. Producer-only methods returns builder
> >>> casted to FileEndpointProducerBuilder. Consumer-only methods returns
> >>> builder casted to FileEndpointConsumerBuilder;
> >>>
> >>> With this, first call to builder method, which is consumer-only returns
> >>> FileEndpointConsumerBuilder and user is forced to use only common and
> >>> consumer-only options for the subsequent calls.
> >>>
> >>> This is a bit strange, to have two different contracts for the same
> >>> method in interfaces, but compiller does not complain about it.
> >>>
> >>> Small silly draft:
> >>>
> >>> public interface FileEndpointProducerBuilder extends EndpointBuilder {
> >>> FileEndpointProducerBuilder fileExist(GenericFileExist
> >>> fileExist); // producer only
> >>> FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
> >>> common
> >>> FileEndpointProducerBuilder flatten(boolean flatten); //common
> >>> }
> >>>
> >>> public interface FileEndpointConsumerBuilder extends EndpointBuilder {
> >>> FileEndpointConsumerBuilder recursive(boolean recursive); //
> >>> consumer only
> >>> FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
> >>> //common
> >>> FileEndpointConsumerBuilder flatten(boolean flatten); //common
> >>> }
> >>>
> >>> public class FileEndpointBuilderImpl implements
> >>> FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
> >>> private FileEndpoint endpoint;
> >>>
> >>> public FileEndpointBuilderImpl(String path) {
> >>> this.endpoint = new FileEndpoint();
> >>> this.endpoint.setFile(new File(path)); // required
> >>> }
> >>>
> >>> public FileEndpointConsumerBuilder recursive(boolean
> recursive)
> >>> { // consumer only, return FileEndpointConsumerBuilder
> >>> this.endpoint.setRecursive(recursive);
> >>> return this;
> >>> }
> >>>
> >>> public FileEndpointProducerBuilder fileExist(GenericFileExist
> >>> fileExist) { // producer only, return FileEndpointProducerBuilder
> >>> this.endpoint.setFileExist(fileExist);
> >>> return this;
> >>> }
> >>>
> >>> public FileEndpointBuilderImpl autoCreate(boolean autoCreate)
> {
> >>> // common, return FileEndpointBuilderImpl which allows user to use all
> >>> options
> >>> this.endpoint.setAutoCreate(autoCreate);
> >>> return this;
> >>> }
> >>>
> >>> public FileEndpointBuilderImpl flatten(boolean autoCreate) {
> //
> >>> common, return FileEndpointBuilderImpl which allows user to use all
> >>> options
> >>> this.endpoint.setFlatten(autoCreate);
> >>> return this;
> >>> }
> >>>
> >>> @Override
> >>> public Endpoint build() {
> >>> return endpoint;
> >>> }
> >>> }
> >>>
> >>>
> >>> Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
> >>> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com>
> a
> >>> > écrit :
> >>> >
> >>> >> Hey Guillaume, nice feature indeed.
> >>> >> Just a detail when reading the example, I think one could be
> >>> surprised to
> >>> >> have x2 from/to at first glance, I mean:
> >>> >> from(fromFile(... and to(toFile(...
> >>> >>
> >>> >>
> >>> > I do agree. My original idea was to only use file(xxx), but one
> >>> constraint
> >>> > is to have a different type for consumers and producers because they
> >>> have
> >>> > different options, so we can't use the same method name. So the
> >>> current
> >>> > design is a fallback because I haven't found anything better, but I'm
> >>> open
> >>> > to suggestions ...
> >>> >
> >>> >
> >>> >
> >>> >> My 2 cents,
> >>> >> Alex
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
> >>> wrote:
> >>> >>
> >>> >>> I think I'm done with a first usable pass at the endpoint DSL.
> >>> >>> I've removed the getters/setters, added 2 flavors of fluent methods
> >>> (one
> >>> >>> with the real java type, another one with a String to allow
> >>> references
> >>> >> and
> >>> >>> property placeholder processing), renamed the generated classes to
> >>> >>> XxxEndpointBuilder and cleaned things a bit.
> >>> >>> In order to access this API, one would create an
> EndpointRouteBuilder
> >>> >>> anonymous class instead of the usual RouteBuilder (see below). The
> >>> only
> >>> >>> difference is that it gives immediate access to the fromXxx() and
> >>> toXxx()
> >>> >>> methods that are generated as default methods on the interface, so
> >>> >> there's
> >>> >>> no need to import anything else.
> >>> >>> Please have a look and let me know what you think or if we see
> >>> anything
> >>> >> to
> >>> >>> improve.
> >>> >>>
> >>> >>> Cheers,
> >>> >>> Guillaume
> >>> >>>
> >>> >>> protected RouteBuilder createRouteBuilder() throws Exception {
> >>> >>> return new EndpointRouteBuilder() {
> >>> >>> @Override
> >>> >>> public void configure() throws Exception {
> >>> >>>
> >>> from(fromFile(start).initialDelay(0).delay(10).move(done +
> >>> >>> "/${file:name}"))
> >>> >>> .to(toMock("result"));
> >>> >>> }
> >>> >>> };
> >>> >>> }
> >>> >>>
> >>> >>>
> >>> >>> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> >>> >> écrit :
> >>> >>>> I just pushed a branch called "endpoint-dsl".
> >>> >>>>
> >>> >>>> My goal is to experiment with an auto-generated DSL for endpoints,
> >>> >> mainly
> >>> >>>> to have a complete and type-safe java DSL for endpoints instead of
> >>> >> using
> >>> >>>> URI containing all the parameters. Right now, it compiles but
> isn't
> >>> >>> really
> >>> >>>> usable at a DSL.
> >>> >>>> I'll get back as soon as I have something which can actually be
> >>> used so
> >>> >>>> that we can discuss further various options.
> >>> >>>> My rough goal is to be able to write something like:
> >>> >>>>
> >>> >>>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
> >>> >>>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> >>> >>>> .to(mock("result"))
> >>> >>>>
> >>> >>>> instead of
> >>> >>>>
> >>> >>>> from(
> >>> >>>>
> >>> >>
> >>>
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> >>> >>>> )
> >>> >>>> .to("mock:result")
> >>> >>>>
> >>> >>>> Stay tuned !
> >>> >>>>
> >>> >>>> --
> >>> >>>> ------------------------
> >>> >>>> Guillaume Nodet
> >>> >>>>
> >>> >>>>
> >>> >>> --
> >>> >>> ------------------------
> >>> >>> Guillaume Nodet
> >>> >>>
> >>> >
> >>>
> >>>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >>
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
So I pushed my latest changes, which include the work discussed here.
I really like it better, for both having a single method for both
consumers/producers (while still having separate interfaces when the
options are specific to the consumer/producer), and having a separate set
of interfaces for advanced options, so that the choice when completing is
minimized.
Let me know what you think...
The file endpoint builder DSL is available at
https://github.com/apache/camel/blob/endpoint-dsl/core/camel-core/src/main/java/org/apache/camel/model/endpoint/FileEndpointBuilderFactory.java
Le mer. 12 juin 2019 à 19:17, Guillaume Nodet <gn...@apache.org> a écrit :
> A compiling prototype is available at
> https://gist.github.com/gnodet/ad5e00ec8e6855bbdab3d6f58d8ced80
>
> However, this can't be combined with Claus' suggestion to keep some kind
> of hierarchy between the builders.
>
> Though we could make the properties flagged with the "advanced" label
> accessible using the advanced() / basic() methods in the below example.
> https://gist.github.com/gnodet/aa393baada9c0819cfcba01d7261b943
>
> So at the end, the choice is between
>
> - two methods fromFile() / toFile() and the ability to make options in
> a hierarchy
> - a single method file() for both consumers / producers with the
> ability to group advanced options in a separate interface to split them a
> bit from the basic options
>
> I would tend to favour the second option, as I think the benefit of moving
> the advanced properties apart is greater than the ability to have them in a
> hierarchy.
>
> Cheers,
> Guillaume
>
> Le mer. 12 juin 2019 à 17:15, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>> I'll experiment a bit, but your suggestion looks promising.
>>
>> Le mer. 12 juin 2019 à 15:24, Jan Bednář <pu...@janbednar.eu> a écrit :
>>
>>> Hi all, one idea, how to keep clean file() instead fromFile() and
>>> toFile(). I have not checked full code of source branch, so apologize,
>>> if this is not possible to integrate for some reason.
>>>
>>> I think it is not needed to know if you are consumer or producer when
>>> creating builder. It can be switched to consumer/producer builder
>>> afterwards, when consumer/producer specific builder method is used.
>>>
>>> There could be two interfaces FileEndpointConsumerBuilder and
>>> FileEndpointProducerBuilder. Consumer builder interface holds common and
>>> consumer-only options. Producer builder interface holds common and
>>> producer-only options. Builder class implements
>>> FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
>>> methods returns builder self. Producer-only methods returns builder
>>> casted to FileEndpointProducerBuilder. Consumer-only methods returns
>>> builder casted to FileEndpointConsumerBuilder;
>>>
>>> With this, first call to builder method, which is consumer-only returns
>>> FileEndpointConsumerBuilder and user is forced to use only common and
>>> consumer-only options for the subsequent calls.
>>>
>>> This is a bit strange, to have two different contracts for the same
>>> method in interfaces, but compiller does not complain about it.
>>>
>>> Small silly draft:
>>>
>>> public interface FileEndpointProducerBuilder extends EndpointBuilder {
>>> FileEndpointProducerBuilder fileExist(GenericFileExist
>>> fileExist); // producer only
>>> FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
>>> common
>>> FileEndpointProducerBuilder flatten(boolean flatten); //common
>>> }
>>>
>>> public interface FileEndpointConsumerBuilder extends EndpointBuilder {
>>> FileEndpointConsumerBuilder recursive(boolean recursive); //
>>> consumer only
>>> FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
>>> //common
>>> FileEndpointConsumerBuilder flatten(boolean flatten); //common
>>> }
>>>
>>> public class FileEndpointBuilderImpl implements
>>> FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
>>> private FileEndpoint endpoint;
>>>
>>> public FileEndpointBuilderImpl(String path) {
>>> this.endpoint = new FileEndpoint();
>>> this.endpoint.setFile(new File(path)); // required
>>> }
>>>
>>> public FileEndpointConsumerBuilder recursive(boolean recursive)
>>> { // consumer only, return FileEndpointConsumerBuilder
>>> this.endpoint.setRecursive(recursive);
>>> return this;
>>> }
>>>
>>> public FileEndpointProducerBuilder fileExist(GenericFileExist
>>> fileExist) { // producer only, return FileEndpointProducerBuilder
>>> this.endpoint.setFileExist(fileExist);
>>> return this;
>>> }
>>>
>>> public FileEndpointBuilderImpl autoCreate(boolean autoCreate) {
>>> // common, return FileEndpointBuilderImpl which allows user to use all
>>> options
>>> this.endpoint.setAutoCreate(autoCreate);
>>> return this;
>>> }
>>>
>>> public FileEndpointBuilderImpl flatten(boolean autoCreate) { //
>>> common, return FileEndpointBuilderImpl which allows user to use all
>>> options
>>> this.endpoint.setFlatten(autoCreate);
>>> return this;
>>> }
>>>
>>> @Override
>>> public Endpoint build() {
>>> return endpoint;
>>> }
>>> }
>>>
>>>
>>> Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
>>> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
>>> > écrit :
>>> >
>>> >> Hey Guillaume, nice feature indeed.
>>> >> Just a detail when reading the example, I think one could be
>>> surprised to
>>> >> have x2 from/to at first glance, I mean:
>>> >> from(fromFile(... and to(toFile(...
>>> >>
>>> >>
>>> > I do agree. My original idea was to only use file(xxx), but one
>>> constraint
>>> > is to have a different type for consumers and producers because they
>>> have
>>> > different options, so we can't use the same method name. So the
>>> current
>>> > design is a fallback because I haven't found anything better, but I'm
>>> open
>>> > to suggestions ...
>>> >
>>> >
>>> >
>>> >> My 2 cents,
>>> >> Alex
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>> >>
>>> >>> I think I'm done with a first usable pass at the endpoint DSL.
>>> >>> I've removed the getters/setters, added 2 flavors of fluent methods
>>> (one
>>> >>> with the real java type, another one with a String to allow
>>> references
>>> >> and
>>> >>> property placeholder processing), renamed the generated classes to
>>> >>> XxxEndpointBuilder and cleaned things a bit.
>>> >>> In order to access this API, one would create an EndpointRouteBuilder
>>> >>> anonymous class instead of the usual RouteBuilder (see below). The
>>> only
>>> >>> difference is that it gives immediate access to the fromXxx() and
>>> toXxx()
>>> >>> methods that are generated as default methods on the interface, so
>>> >> there's
>>> >>> no need to import anything else.
>>> >>> Please have a look and let me know what you think or if we see
>>> anything
>>> >> to
>>> >>> improve.
>>> >>>
>>> >>> Cheers,
>>> >>> Guillaume
>>> >>>
>>> >>> protected RouteBuilder createRouteBuilder() throws Exception {
>>> >>> return new EndpointRouteBuilder() {
>>> >>> @Override
>>> >>> public void configure() throws Exception {
>>> >>>
>>> from(fromFile(start).initialDelay(0).delay(10).move(done +
>>> >>> "/${file:name}"))
>>> >>> .to(toMock("result"));
>>> >>> }
>>> >>> };
>>> >>> }
>>> >>>
>>> >>>
>>> >>> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
>>> >> écrit :
>>> >>>> I just pushed a branch called "endpoint-dsl".
>>> >>>>
>>> >>>> My goal is to experiment with an auto-generated DSL for endpoints,
>>> >> mainly
>>> >>>> to have a complete and type-safe java DSL for endpoints instead of
>>> >> using
>>> >>>> URI containing all the parameters. Right now, it compiles but isn't
>>> >>> really
>>> >>>> usable at a DSL.
>>> >>>> I'll get back as soon as I have something which can actually be
>>> used so
>>> >>>> that we can discuss further various options.
>>> >>>> My rough goal is to be able to write something like:
>>> >>>>
>>> >>>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
>>> >>>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
>>> >>>> .to(mock("result"))
>>> >>>>
>>> >>>> instead of
>>> >>>>
>>> >>>> from(
>>> >>>>
>>> >>
>>> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
>>> >>>> )
>>> >>>> .to("mock:result")
>>> >>>>
>>> >>>> Stay tuned !
>>> >>>>
>>> >>>> --
>>> >>>> ------------------------
>>> >>>> Guillaume Nodet
>>> >>>>
>>> >>>>
>>> >>> --
>>> >>> ------------------------
>>> >>> Guillaume Nodet
>>> >>>
>>> >
>>>
>>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
A compiling prototype is available at
https://gist.github.com/gnodet/ad5e00ec8e6855bbdab3d6f58d8ced80
However, this can't be combined with Claus' suggestion to keep some kind of
hierarchy between the builders.
Though we could make the properties flagged with the "advanced" label
accessible using the advanced() / basic() methods in the below example.
https://gist.github.com/gnodet/aa393baada9c0819cfcba01d7261b943
So at the end, the choice is between
- two methods fromFile() / toFile() and the ability to make options in a
hierarchy
- a single method file() for both consumers / producers with the ability
to group advanced options in a separate interface to split them a bit from
the basic options
I would tend to favour the second option, as I think the benefit of moving
the advanced properties apart is greater than the ability to have them in a
hierarchy.
Cheers,
Guillaume
Le mer. 12 juin 2019 à 17:15, Guillaume Nodet <gn...@apache.org> a écrit :
> I'll experiment a bit, but your suggestion looks promising.
>
> Le mer. 12 juin 2019 à 15:24, Jan Bednář <pu...@janbednar.eu> a écrit :
>
>> Hi all, one idea, how to keep clean file() instead fromFile() and
>> toFile(). I have not checked full code of source branch, so apologize,
>> if this is not possible to integrate for some reason.
>>
>> I think it is not needed to know if you are consumer or producer when
>> creating builder. It can be switched to consumer/producer builder
>> afterwards, when consumer/producer specific builder method is used.
>>
>> There could be two interfaces FileEndpointConsumerBuilder and
>> FileEndpointProducerBuilder. Consumer builder interface holds common and
>> consumer-only options. Producer builder interface holds common and
>> producer-only options. Builder class implements
>> FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
>> methods returns builder self. Producer-only methods returns builder
>> casted to FileEndpointProducerBuilder. Consumer-only methods returns
>> builder casted to FileEndpointConsumerBuilder;
>>
>> With this, first call to builder method, which is consumer-only returns
>> FileEndpointConsumerBuilder and user is forced to use only common and
>> consumer-only options for the subsequent calls.
>>
>> This is a bit strange, to have two different contracts for the same
>> method in interfaces, but compiller does not complain about it.
>>
>> Small silly draft:
>>
>> public interface FileEndpointProducerBuilder extends EndpointBuilder {
>> FileEndpointProducerBuilder fileExist(GenericFileExist
>> fileExist); // producer only
>> FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
>> common
>> FileEndpointProducerBuilder flatten(boolean flatten); //common
>> }
>>
>> public interface FileEndpointConsumerBuilder extends EndpointBuilder {
>> FileEndpointConsumerBuilder recursive(boolean recursive); //
>> consumer only
>> FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
>> //common
>> FileEndpointConsumerBuilder flatten(boolean flatten); //common
>> }
>>
>> public class FileEndpointBuilderImpl implements
>> FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
>> private FileEndpoint endpoint;
>>
>> public FileEndpointBuilderImpl(String path) {
>> this.endpoint = new FileEndpoint();
>> this.endpoint.setFile(new File(path)); // required
>> }
>>
>> public FileEndpointConsumerBuilder recursive(boolean recursive)
>> { // consumer only, return FileEndpointConsumerBuilder
>> this.endpoint.setRecursive(recursive);
>> return this;
>> }
>>
>> public FileEndpointProducerBuilder fileExist(GenericFileExist
>> fileExist) { // producer only, return FileEndpointProducerBuilder
>> this.endpoint.setFileExist(fileExist);
>> return this;
>> }
>>
>> public FileEndpointBuilderImpl autoCreate(boolean autoCreate) {
>> // common, return FileEndpointBuilderImpl which allows user to use all
>> options
>> this.endpoint.setAutoCreate(autoCreate);
>> return this;
>> }
>>
>> public FileEndpointBuilderImpl flatten(boolean autoCreate) { //
>> common, return FileEndpointBuilderImpl which allows user to use all
>> options
>> this.endpoint.setFlatten(autoCreate);
>> return this;
>> }
>>
>> @Override
>> public Endpoint build() {
>> return endpoint;
>> }
>> }
>>
>>
>> Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
>> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
>> > écrit :
>> >
>> >> Hey Guillaume, nice feature indeed.
>> >> Just a detail when reading the example, I think one could be surprised
>> to
>> >> have x2 from/to at first glance, I mean:
>> >> from(fromFile(... and to(toFile(...
>> >>
>> >>
>> > I do agree. My original idea was to only use file(xxx), but one
>> constraint
>> > is to have a different type for consumers and producers because they
>> have
>> > different options, so we can't use the same method name. So the current
>> > design is a fallback because I haven't found anything better, but I'm
>> open
>> > to suggestions ...
>> >
>> >
>> >
>> >> My 2 cents,
>> >> Alex
>> >>
>> >>
>> >>
>> >> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
>> wrote:
>> >>
>> >>> I think I'm done with a first usable pass at the endpoint DSL.
>> >>> I've removed the getters/setters, added 2 flavors of fluent methods
>> (one
>> >>> with the real java type, another one with a String to allow references
>> >> and
>> >>> property placeholder processing), renamed the generated classes to
>> >>> XxxEndpointBuilder and cleaned things a bit.
>> >>> In order to access this API, one would create an EndpointRouteBuilder
>> >>> anonymous class instead of the usual RouteBuilder (see below). The
>> only
>> >>> difference is that it gives immediate access to the fromXxx() and
>> toXxx()
>> >>> methods that are generated as default methods on the interface, so
>> >> there's
>> >>> no need to import anything else.
>> >>> Please have a look and let me know what you think or if we see
>> anything
>> >> to
>> >>> improve.
>> >>>
>> >>> Cheers,
>> >>> Guillaume
>> >>>
>> >>> protected RouteBuilder createRouteBuilder() throws Exception {
>> >>> return new EndpointRouteBuilder() {
>> >>> @Override
>> >>> public void configure() throws Exception {
>> >>> from(fromFile(start).initialDelay(0).delay(10).move(done
>> +
>> >>> "/${file:name}"))
>> >>> .to(toMock("result"));
>> >>> }
>> >>> };
>> >>> }
>> >>>
>> >>>
>> >>> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
>> >> écrit :
>> >>>> I just pushed a branch called "endpoint-dsl".
>> >>>>
>> >>>> My goal is to experiment with an auto-generated DSL for endpoints,
>> >> mainly
>> >>>> to have a complete and type-safe java DSL for endpoints instead of
>> >> using
>> >>>> URI containing all the parameters. Right now, it compiles but isn't
>> >>> really
>> >>>> usable at a DSL.
>> >>>> I'll get back as soon as I have something which can actually be used
>> so
>> >>>> that we can discuss further various options.
>> >>>> My rough goal is to be able to write something like:
>> >>>>
>> >>>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
>> >>>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
>> >>>> .to(mock("result"))
>> >>>>
>> >>>> instead of
>> >>>>
>> >>>> from(
>> >>>>
>> >>
>> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
>> >>>> )
>> >>>> .to("mock:result")
>> >>>>
>> >>>> Stay tuned !
>> >>>>
>> >>>> --
>> >>>> ------------------------
>> >>>> Guillaume Nodet
>> >>>>
>> >>>>
>> >>> --
>> >>> ------------------------
>> >>> Guillaume Nodet
>> >>>
>> >
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
I'll experiment a bit, but your suggestion looks promising.
Le mer. 12 juin 2019 à 15:24, Jan Bednář <pu...@janbednar.eu> a écrit :
> Hi all, one idea, how to keep clean file() instead fromFile() and
> toFile(). I have not checked full code of source branch, so apologize,
> if this is not possible to integrate for some reason.
>
> I think it is not needed to know if you are consumer or producer when
> creating builder. It can be switched to consumer/producer builder
> afterwards, when consumer/producer specific builder method is used.
>
> There could be two interfaces FileEndpointConsumerBuilder and
> FileEndpointProducerBuilder. Consumer builder interface holds common and
> consumer-only options. Producer builder interface holds common and
> producer-only options. Builder class implements
> FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
> methods returns builder self. Producer-only methods returns builder
> casted to FileEndpointProducerBuilder. Consumer-only methods returns
> builder casted to FileEndpointConsumerBuilder;
>
> With this, first call to builder method, which is consumer-only returns
> FileEndpointConsumerBuilder and user is forced to use only common and
> consumer-only options for the subsequent calls.
>
> This is a bit strange, to have two different contracts for the same
> method in interfaces, but compiller does not complain about it.
>
> Small silly draft:
>
> public interface FileEndpointProducerBuilder extends EndpointBuilder {
> FileEndpointProducerBuilder fileExist(GenericFileExist
> fileExist); // producer only
> FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
> common
> FileEndpointProducerBuilder flatten(boolean flatten); //common
> }
>
> public interface FileEndpointConsumerBuilder extends EndpointBuilder {
> FileEndpointConsumerBuilder recursive(boolean recursive); //
> consumer only
> FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
> //common
> FileEndpointConsumerBuilder flatten(boolean flatten); //common
> }
>
> public class FileEndpointBuilderImpl implements
> FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
> private FileEndpoint endpoint;
>
> public FileEndpointBuilderImpl(String path) {
> this.endpoint = new FileEndpoint();
> this.endpoint.setFile(new File(path)); // required
> }
>
> public FileEndpointConsumerBuilder recursive(boolean recursive)
> { // consumer only, return FileEndpointConsumerBuilder
> this.endpoint.setRecursive(recursive);
> return this;
> }
>
> public FileEndpointProducerBuilder fileExist(GenericFileExist
> fileExist) { // producer only, return FileEndpointProducerBuilder
> this.endpoint.setFileExist(fileExist);
> return this;
> }
>
> public FileEndpointBuilderImpl autoCreate(boolean autoCreate) {
> // common, return FileEndpointBuilderImpl which allows user to use all
> options
> this.endpoint.setAutoCreate(autoCreate);
> return this;
> }
>
> public FileEndpointBuilderImpl flatten(boolean autoCreate) { //
> common, return FileEndpointBuilderImpl which allows user to use all options
> this.endpoint.setFlatten(autoCreate);
> return this;
> }
>
> @Override
> public Endpoint build() {
> return endpoint;
> }
> }
>
>
> Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
> > écrit :
> >
> >> Hey Guillaume, nice feature indeed.
> >> Just a detail when reading the example, I think one could be surprised
> to
> >> have x2 from/to at first glance, I mean:
> >> from(fromFile(... and to(toFile(...
> >>
> >>
> > I do agree. My original idea was to only use file(xxx), but one
> constraint
> > is to have a different type for consumers and producers because they have
> > different options, so we can't use the same method name. So the current
> > design is a fallback because I haven't found anything better, but I'm
> open
> > to suggestions ...
> >
> >
> >
> >> My 2 cents,
> >> Alex
> >>
> >>
> >>
> >> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> >>
> >>> I think I'm done with a first usable pass at the endpoint DSL.
> >>> I've removed the getters/setters, added 2 flavors of fluent methods
> (one
> >>> with the real java type, another one with a String to allow references
> >> and
> >>> property placeholder processing), renamed the generated classes to
> >>> XxxEndpointBuilder and cleaned things a bit.
> >>> In order to access this API, one would create an EndpointRouteBuilder
> >>> anonymous class instead of the usual RouteBuilder (see below). The
> only
> >>> difference is that it gives immediate access to the fromXxx() and
> toXxx()
> >>> methods that are generated as default methods on the interface, so
> >> there's
> >>> no need to import anything else.
> >>> Please have a look and let me know what you think or if we see anything
> >> to
> >>> improve.
> >>>
> >>> Cheers,
> >>> Guillaume
> >>>
> >>> protected RouteBuilder createRouteBuilder() throws Exception {
> >>> return new EndpointRouteBuilder() {
> >>> @Override
> >>> public void configure() throws Exception {
> >>> from(fromFile(start).initialDelay(0).delay(10).move(done +
> >>> "/${file:name}"))
> >>> .to(toMock("result"));
> >>> }
> >>> };
> >>> }
> >>>
> >>>
> >>> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> >> écrit :
> >>>> I just pushed a branch called "endpoint-dsl".
> >>>>
> >>>> My goal is to experiment with an auto-generated DSL for endpoints,
> >> mainly
> >>>> to have a complete and type-safe java DSL for endpoints instead of
> >> using
> >>>> URI containing all the parameters. Right now, it compiles but isn't
> >>> really
> >>>> usable at a DSL.
> >>>> I'll get back as soon as I have something which can actually be used
> so
> >>>> that we can discuss further various options.
> >>>> My rough goal is to be able to write something like:
> >>>>
> >>>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
> >>>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> >>>> .to(mock("result"))
> >>>>
> >>>> instead of
> >>>>
> >>>> from(
> >>>>
> >>
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> >>>> )
> >>>> .to("mock:result")
> >>>>
> >>>> Stay tuned !
> >>>>
> >>>> --
> >>>> ------------------------
> >>>> Guillaume Nodet
> >>>>
> >>>>
> >>> --
> >>> ------------------------
> >>> Guillaume Nodet
> >>>
> >
>
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Jan Bednář <pu...@janbednar.eu>.
Hi all, one idea, how to keep clean file() instead fromFile() and
toFile(). I have not checked full code of source branch, so apologize,
if this is not possible to integrate for some reason.
I think it is not needed to know if you are consumer or producer when
creating builder. It can be switched to consumer/producer builder
afterwards, when consumer/producer specific builder method is used.
There could be two interfaces FileEndpointConsumerBuilder and
FileEndpointProducerBuilder. Consumer builder interface holds common and
consumer-only options. Producer builder interface holds common and
producer-only options. Builder class implements
FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
methods returns builder self. Producer-only methods returns builder
casted to FileEndpointProducerBuilder. Consumer-only methods returns
builder casted to FileEndpointConsumerBuilder;
With this, first call to builder method, which is consumer-only returns
FileEndpointConsumerBuilder and user is forced to use only common and
consumer-only options for the subsequent calls.
This is a bit strange, to have two different contracts for the same
method in interfaces, but compiller does not complain about it.
Small silly draft:
public interface FileEndpointProducerBuilder extends EndpointBuilder {
FileEndpointProducerBuilder fileExist(GenericFileExist
fileExist); // producer only
FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
common
FileEndpointProducerBuilder flatten(boolean flatten); //common
}
public interface FileEndpointConsumerBuilder extends EndpointBuilder {
FileEndpointConsumerBuilder recursive(boolean recursive); //
consumer only
FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
//common
FileEndpointConsumerBuilder flatten(boolean flatten); //common
}
public class FileEndpointBuilderImpl implements
FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
private FileEndpoint endpoint;
public FileEndpointBuilderImpl(String path) {
this.endpoint = new FileEndpoint();
this.endpoint.setFile(new File(path)); // required
}
public FileEndpointConsumerBuilder recursive(boolean recursive)
{ // consumer only, return FileEndpointConsumerBuilder
this.endpoint.setRecursive(recursive);
return this;
}
public FileEndpointProducerBuilder fileExist(GenericFileExist
fileExist) { // producer only, return FileEndpointProducerBuilder
this.endpoint.setFileExist(fileExist);
return this;
}
public FileEndpointBuilderImpl autoCreate(boolean autoCreate) {
// common, return FileEndpointBuilderImpl which allows user to use all
options
this.endpoint.setAutoCreate(autoCreate);
return this;
}
public FileEndpointBuilderImpl flatten(boolean autoCreate) { //
common, return FileEndpointBuilderImpl which allows user to use all options
this.endpoint.setFlatten(autoCreate);
return this;
}
@Override
public Endpoint build() {
return endpoint;
}
}
Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
> Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
> écrit :
>
>> Hey Guillaume, nice feature indeed.
>> Just a detail when reading the example, I think one could be surprised to
>> have x2 from/to at first glance, I mean:
>> from(fromFile(... and to(toFile(...
>>
>>
> I do agree. My original idea was to only use file(xxx), but one constraint
> is to have a different type for consumers and producers because they have
> different options, so we can't use the same method name. So the current
> design is a fallback because I haven't found anything better, but I'm open
> to suggestions ...
>
>
>
>> My 2 cents,
>> Alex
>>
>>
>>
>> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
>>
>>> I think I'm done with a first usable pass at the endpoint DSL.
>>> I've removed the getters/setters, added 2 flavors of fluent methods (one
>>> with the real java type, another one with a String to allow references
>> and
>>> property placeholder processing), renamed the generated classes to
>>> XxxEndpointBuilder and cleaned things a bit.
>>> In order to access this API, one would create an EndpointRouteBuilder
>>> anonymous class instead of the usual RouteBuilder (see below). The only
>>> difference is that it gives immediate access to the fromXxx() and toXxx()
>>> methods that are generated as default methods on the interface, so
>> there's
>>> no need to import anything else.
>>> Please have a look and let me know what you think or if we see anything
>> to
>>> improve.
>>>
>>> Cheers,
>>> Guillaume
>>>
>>> protected RouteBuilder createRouteBuilder() throws Exception {
>>> return new EndpointRouteBuilder() {
>>> @Override
>>> public void configure() throws Exception {
>>> from(fromFile(start).initialDelay(0).delay(10).move(done +
>>> "/${file:name}"))
>>> .to(toMock("result"));
>>> }
>>> };
>>> }
>>>
>>>
>>> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
>> écrit :
>>>> I just pushed a branch called "endpoint-dsl".
>>>>
>>>> My goal is to experiment with an auto-generated DSL for endpoints,
>> mainly
>>>> to have a complete and type-safe java DSL for endpoints instead of
>> using
>>>> URI containing all the parameters. Right now, it compiles but isn't
>>> really
>>>> usable at a DSL.
>>>> I'll get back as soon as I have something which can actually be used so
>>>> that we can discuss further various options.
>>>> My rough goal is to be able to write something like:
>>>>
>>>> from(file("target/data/foo").delay(4000).backoffMultiplier(4
>>>> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
>>>> .to(mock("result"))
>>>>
>>>> instead of
>>>>
>>>> from(
>>>>
>> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
>>>> )
>>>> .to("mock:result")
>>>>
>>>> Stay tuned !
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>>
>>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
It should not be a problem, I've just pushed some changes which take care
about the endpoint dsl when retrieving the URI on the From/SendDefinition,
similar to what is used in the blueprint namespace handler. From the uri,
you can safely extract the scheme and thus the endpoint.
If I'm missing something, please point me to the relevant code so that I
can add the missing bits.
Le mer. 12 juin 2019 à 15:38, Willem Jiang <wi...@gmail.com> a
écrit :
> When we deploy the camel routes with the help camel-k into k8s, we
> still need to leverage the camel-catalog to find out the dependencies.
> Otherwise we need to specify the dependency by using command line
> options for camel-k to create the project with right third party
> dependencies.
> I think the challenge part is how can we do it with the endpoint-dsl
> without specifying the dependencies.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jun 12, 2019 at 1:16 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > Le mer. 12 juin 2019 à 02:37, Willem Jiang <wi...@gmail.com> a
> > écrit :
> >
> > > Hi Guillaume,
> > >
> > > The endpoint-dsl is really helpful for camel to verify the endpoint
> > > setting in the compile time.
> > > Now I just have a quick question about how does the camel runtime
> > > detect the dependencies of camel route?
> > > With the endpoint URI we could use the camel-catalog do this kind of
> > > work, with the endpoint-dsl we need to figure out another way to do
> > > it.
> > >
> >
> > Are you talking about the fact that the blueprint namespace handler
> > try to find all the component dependencies ? Or is there any other
> > place in the code that does a similar thing ?
> > For the blueprint, I agree that could be a problem, but in reality it
> > should
> > not because blueprint uses the XML DSL which is not supported by
> > the endpoint DSL we're talking.
> > If there is something else, I could make sure it works too. The endpoint
> > builders are aware of the scheme, so we'd just need to add a getter
> > so that it can be checked.
> >
> > Cheers,
> > Guillaume
> >
> >
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> > > >
> > > > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com>
> a
> > > > écrit :
> > > >
> > > > > Hey Guillaume, nice feature indeed.
> > > > > Just a detail when reading the example, I think one could be
> surprised
> > > to
> > > > > have x2 from/to at first glance, I mean:
> > > > > from(fromFile(... and to(toFile(...
> > > > >
> > > > >
> > > > I do agree. My original idea was to only use file(xxx), but one
> > > constraint
> > > > is to have a different type for consumers and producers because they
> have
> > > > different options, so we can't use the same method name. So the
> current
> > > > design is a fallback because I haven't found anything better, but I'm
> > > open
> > > > to suggestions ...
> > > >
> > > >
> > > >
> > > > > My 2 cents,
> > > > > Alex
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gnodet@apache.org
> >
> > > wrote:
> > > > >
> > > > > > I think I'm done with a first usable pass at the endpoint DSL.
> > > > > > I've removed the getters/setters, added 2 flavors of fluent
> methods
> > > (one
> > > > > > with the real java type, another one with a String to allow
> > > references
> > > > > and
> > > > > > property placeholder processing), renamed the generated classes
> to
> > > > > > XxxEndpointBuilder and cleaned things a bit.
> > > > > > In order to access this API, one would create an
> EndpointRouteBuilder
> > > > > > anonymous class instead of the usual RouteBuilder (see below).
> The
> > > only
> > > > > > difference is that it gives immediate access to the fromXxx() and
> > > toXxx()
> > > > > > methods that are generated as default methods on the interface,
> so
> > > > > there's
> > > > > > no need to import anything else.
> > > > > > Please have a look and let me know what you think or if we see
> > > anything
> > > > > to
> > > > > > improve.
> > > > > >
> > > > > > Cheers,
> > > > > > Guillaume
> > > > > >
> > > > > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > > > > return new EndpointRouteBuilder() {
> > > > > > @Override
> > > > > > public void configure() throws Exception {
> > > > > >
> from(fromFile(start).initialDelay(0).delay(10).move(done
> > > +
> > > > > > "/${file:name}"))
> > > > > > .to(toMock("result"));
> > > > > > }
> > > > > > };
> > > > > > }
> > > > > >
> > > > > >
> > > > > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org>
> a
> > > > > écrit :
> > > > > >
> > > > > > > I just pushed a branch called "endpoint-dsl".
> > > > > > >
> > > > > > > My goal is to experiment with an auto-generated DSL for
> endpoints,
> > > > > mainly
> > > > > > > to have a complete and type-safe java DSL for endpoints
> instead of
> > > > > using
> > > > > > > URI containing all the parameters. Right now, it compiles but
> > > isn't
> > > > > > really
> > > > > > > usable at a DSL.
> > > > > > > I'll get back as soon as I have something which can actually be
> > > used so
> > > > > > > that we can discuss further various options.
> > > > > > > My rough goal is to be able to write something like:
> > > > > > >
> > > > > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > > > > .to(mock("result"))
> > > > > > >
> > > > > > > instead of
> > > > > > >
> > > > > > > from(
> > > > > > >
> > > > > >
> > > > >
> > >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > > > > )
> > > > > > > .to("mock:result")
> > > > > > >
> > > > > > > Stay tuned !
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Willem Jiang <wi...@gmail.com>.
When we deploy the camel routes with the help camel-k into k8s, we
still need to leverage the camel-catalog to find out the dependencies.
Otherwise we need to specify the dependency by using command line
options for camel-k to create the project with right third party
dependencies.
I think the challenge part is how can we do it with the endpoint-dsl
without specifying the dependencies.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Jun 12, 2019 at 1:16 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> Le mer. 12 juin 2019 à 02:37, Willem Jiang <wi...@gmail.com> a
> écrit :
>
> > Hi Guillaume,
> >
> > The endpoint-dsl is really helpful for camel to verify the endpoint
> > setting in the compile time.
> > Now I just have a quick question about how does the camel runtime
> > detect the dependencies of camel route?
> > With the endpoint URI we could use the camel-catalog do this kind of
> > work, with the endpoint-dsl we need to figure out another way to do
> > it.
> >
>
> Are you talking about the fact that the blueprint namespace handler
> try to find all the component dependencies ? Or is there any other
> place in the code that does a similar thing ?
> For the blueprint, I agree that could be a problem, but in reality it
> should
> not because blueprint uses the XML DSL which is not supported by
> the endpoint DSL we're talking.
> If there is something else, I could make sure it works too. The endpoint
> builders are aware of the scheme, so we'd just need to add a getter
> so that it can be checked.
>
> Cheers,
> Guillaume
>
>
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet <gn...@apache.org> wrote:
> > >
> > > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
> > > écrit :
> > >
> > > > Hey Guillaume, nice feature indeed.
> > > > Just a detail when reading the example, I think one could be surprised
> > to
> > > > have x2 from/to at first glance, I mean:
> > > > from(fromFile(... and to(toFile(...
> > > >
> > > >
> > > I do agree. My original idea was to only use file(xxx), but one
> > constraint
> > > is to have a different type for consumers and producers because they have
> > > different options, so we can't use the same method name. So the current
> > > design is a fallback because I haven't found anything better, but I'm
> > open
> > > to suggestions ...
> > >
> > >
> > >
> > > > My 2 cents,
> > > > Alex
> > > >
> > > >
> > > >
> > > > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > > >
> > > > > I think I'm done with a first usable pass at the endpoint DSL.
> > > > > I've removed the getters/setters, added 2 flavors of fluent methods
> > (one
> > > > > with the real java type, another one with a String to allow
> > references
> > > > and
> > > > > property placeholder processing), renamed the generated classes to
> > > > > XxxEndpointBuilder and cleaned things a bit.
> > > > > In order to access this API, one would create an EndpointRouteBuilder
> > > > > anonymous class instead of the usual RouteBuilder (see below). The
> > only
> > > > > difference is that it gives immediate access to the fromXxx() and
> > toXxx()
> > > > > methods that are generated as default methods on the interface, so
> > > > there's
> > > > > no need to import anything else.
> > > > > Please have a look and let me know what you think or if we see
> > anything
> > > > to
> > > > > improve.
> > > > >
> > > > > Cheers,
> > > > > Guillaume
> > > > >
> > > > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > > > return new EndpointRouteBuilder() {
> > > > > @Override
> > > > > public void configure() throws Exception {
> > > > > from(fromFile(start).initialDelay(0).delay(10).move(done
> > +
> > > > > "/${file:name}"))
> > > > > .to(toMock("result"));
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> > > > écrit :
> > > > >
> > > > > > I just pushed a branch called "endpoint-dsl".
> > > > > >
> > > > > > My goal is to experiment with an auto-generated DSL for endpoints,
> > > > mainly
> > > > > > to have a complete and type-safe java DSL for endpoints instead of
> > > > using
> > > > > > URI containing all the parameters. Right now, it compiles but
> > isn't
> > > > > really
> > > > > > usable at a DSL.
> > > > > > I'll get back as soon as I have something which can actually be
> > used so
> > > > > > that we can discuss further various options.
> > > > > > My rough goal is to be able to write something like:
> > > > > >
> > > > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > > > .to(mock("result"))
> > > > > >
> > > > > > instead of
> > > > > >
> > > > > > from(
> > > > > >
> > > > >
> > > >
> > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > > > )
> > > > > > .to("mock:result")
> > > > > >
> > > > > > Stay tuned !
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
>
>
> --
> ------------------------
> Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 12 juin 2019 à 02:37, Willem Jiang <wi...@gmail.com> a
écrit :
> Hi Guillaume,
>
> The endpoint-dsl is really helpful for camel to verify the endpoint
> setting in the compile time.
> Now I just have a quick question about how does the camel runtime
> detect the dependencies of camel route?
> With the endpoint URI we could use the camel-catalog do this kind of
> work, with the endpoint-dsl we need to figure out another way to do
> it.
>
Are you talking about the fact that the blueprint namespace handler
try to find all the component dependencies ? Or is there any other
place in the code that does a similar thing ?
For the blueprint, I agree that could be a problem, but in reality it
should
not because blueprint uses the XML DSL which is not supported by
the endpoint DSL we're talking.
If there is something else, I could make sure it works too. The endpoint
builders are aware of the scheme, so we'd just need to add a getter
so that it can be checked.
Cheers,
Guillaume
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
> > écrit :
> >
> > > Hey Guillaume, nice feature indeed.
> > > Just a detail when reading the example, I think one could be surprised
> to
> > > have x2 from/to at first glance, I mean:
> > > from(fromFile(... and to(toFile(...
> > >
> > >
> > I do agree. My original idea was to only use file(xxx), but one
> constraint
> > is to have a different type for consumers and producers because they have
> > different options, so we can't use the same method name. So the current
> > design is a fallback because I haven't found anything better, but I'm
> open
> > to suggestions ...
> >
> >
> >
> > > My 2 cents,
> > > Alex
> > >
> > >
> > >
> > > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> > >
> > > > I think I'm done with a first usable pass at the endpoint DSL.
> > > > I've removed the getters/setters, added 2 flavors of fluent methods
> (one
> > > > with the real java type, another one with a String to allow
> references
> > > and
> > > > property placeholder processing), renamed the generated classes to
> > > > XxxEndpointBuilder and cleaned things a bit.
> > > > In order to access this API, one would create an EndpointRouteBuilder
> > > > anonymous class instead of the usual RouteBuilder (see below). The
> only
> > > > difference is that it gives immediate access to the fromXxx() and
> toXxx()
> > > > methods that are generated as default methods on the interface, so
> > > there's
> > > > no need to import anything else.
> > > > Please have a look and let me know what you think or if we see
> anything
> > > to
> > > > improve.
> > > >
> > > > Cheers,
> > > > Guillaume
> > > >
> > > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > > return new EndpointRouteBuilder() {
> > > > @Override
> > > > public void configure() throws Exception {
> > > > from(fromFile(start).initialDelay(0).delay(10).move(done
> +
> > > > "/${file:name}"))
> > > > .to(toMock("result"));
> > > > }
> > > > };
> > > > }
> > > >
> > > >
> > > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> > > écrit :
> > > >
> > > > > I just pushed a branch called "endpoint-dsl".
> > > > >
> > > > > My goal is to experiment with an auto-generated DSL for endpoints,
> > > mainly
> > > > > to have a complete and type-safe java DSL for endpoints instead of
> > > using
> > > > > URI containing all the parameters. Right now, it compiles but
> isn't
> > > > really
> > > > > usable at a DSL.
> > > > > I'll get back as soon as I have something which can actually be
> used so
> > > > > that we can discuss further various options.
> > > > > My rough goal is to be able to write something like:
> > > > >
> > > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > > .to(mock("result"))
> > > > >
> > > > > instead of
> > > > >
> > > > > from(
> > > > >
> > > >
> > >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > > )
> > > > > .to("mock:result")
> > > > >
> > > > > Stay tuned !
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume,
The endpoint-dsl is really helpful for camel to verify the endpoint
setting in the compile time.
Now I just have a quick question about how does the camel runtime
detect the dependencies of camel route?
With the endpoint URI we could use the camel-catalog do this kind of
work, with the endpoint-dsl we need to figure out another way to do
it.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
> écrit :
>
> > Hey Guillaume, nice feature indeed.
> > Just a detail when reading the example, I think one could be surprised to
> > have x2 from/to at first glance, I mean:
> > from(fromFile(... and to(toFile(...
> >
> >
> I do agree. My original idea was to only use file(xxx), but one constraint
> is to have a different type for consumers and producers because they have
> different options, so we can't use the same method name. So the current
> design is a fallback because I haven't found anything better, but I'm open
> to suggestions ...
>
>
>
> > My 2 cents,
> > Alex
> >
> >
> >
> > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > > I think I'm done with a first usable pass at the endpoint DSL.
> > > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > > with the real java type, another one with a String to allow references
> > and
> > > property placeholder processing), renamed the generated classes to
> > > XxxEndpointBuilder and cleaned things a bit.
> > > In order to access this API, one would create an EndpointRouteBuilder
> > > anonymous class instead of the usual RouteBuilder (see below). The only
> > > difference is that it gives immediate access to the fromXxx() and toXxx()
> > > methods that are generated as default methods on the interface, so
> > there's
> > > no need to import anything else.
> > > Please have a look and let me know what you think or if we see anything
> > to
> > > improve.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > return new EndpointRouteBuilder() {
> > > @Override
> > > public void configure() throws Exception {
> > > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > > "/${file:name}"))
> > > .to(toMock("result"));
> > > }
> > > };
> > > }
> > >
> > >
> > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> > écrit :
> > >
> > > > I just pushed a branch called "endpoint-dsl".
> > > >
> > > > My goal is to experiment with an auto-generated DSL for endpoints,
> > mainly
> > > > to have a complete and type-safe java DSL for endpoints instead of
> > using
> > > > URI containing all the parameters. Right now, it compiles but isn't
> > > really
> > > > usable at a DSL.
> > > > I'll get back as soon as I have something which can actually be used so
> > > > that we can discuss further various options.
> > > > My rough goal is to be able to write something like:
> > > >
> > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > .to(mock("result"))
> > > >
> > > > instead of
> > > >
> > > > from(
> > > >
> > >
> > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > )
> > > > .to("mock:result")
> > > >
> > > > Stay tuned !
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
Le mar. 11 juin 2019 à 20:45, Alex Dettinger <al...@gmail.com> a
écrit :
> Hey Guillaume, nice feature indeed.
> Just a detail when reading the example, I think one could be surprised to
> have x2 from/to at first glance, I mean:
> from(fromFile(... and to(toFile(...
>
>
I do agree. My original idea was to only use file(xxx), but one constraint
is to have a different type for consumers and producers because they have
different options, so we can't use the same method name. So the current
design is a fallback because I haven't found anything better, but I'm open
to suggestions ...
> My 2 cents,
> Alex
>
>
>
> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > I think I'm done with a first usable pass at the endpoint DSL.
> > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > with the real java type, another one with a String to allow references
> and
> > property placeholder processing), renamed the generated classes to
> > XxxEndpointBuilder and cleaned things a bit.
> > In order to access this API, one would create an EndpointRouteBuilder
> > anonymous class instead of the usual RouteBuilder (see below). The only
> > difference is that it gives immediate access to the fromXxx() and toXxx()
> > methods that are generated as default methods on the interface, so
> there's
> > no need to import anything else.
> > Please have a look and let me know what you think or if we see anything
> to
> > improve.
> >
> > Cheers,
> > Guillaume
> >
> > protected RouteBuilder createRouteBuilder() throws Exception {
> > return new EndpointRouteBuilder() {
> > @Override
> > public void configure() throws Exception {
> > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > "/${file:name}"))
> > .to(toMock("result"));
> > }
> > };
> > }
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a
> écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints,
> mainly
> > > to have a complete and type-safe java DSL for endpoints instead of
> using
> > > URI containing all the parameters. Right now, it compiles but isn't
> > really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > >
> >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: [HEADS UP] The endpoint-dsl branch
Posted by Alex Dettinger <al...@gmail.com>.
Hey Guillaume, nice feature indeed.
Just a detail when reading the example, I think one could be surprised to
have x2 from/to at first glance, I mean:
from(fromFile(... and to(toFile(...
My 2 cents,
Alex
On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gn...@apache.org> wrote:
> I think I'm done with a first usable pass at the endpoint DSL.
> I've removed the getters/setters, added 2 flavors of fluent methods (one
> with the real java type, another one with a String to allow references and
> property placeholder processing), renamed the generated classes to
> XxxEndpointBuilder and cleaned things a bit.
> In order to access this API, one would create an EndpointRouteBuilder
> anonymous class instead of the usual RouteBuilder (see below). The only
> difference is that it gives immediate access to the fromXxx() and toXxx()
> methods that are generated as default methods on the interface, so there's
> no need to import anything else.
> Please have a look and let me know what you think or if we see anything to
> improve.
>
> Cheers,
> Guillaume
>
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new EndpointRouteBuilder() {
> @Override
> public void configure() throws Exception {
> from(fromFile(start).initialDelay(0).delay(10).move(done +
> "/${file:name}"))
> .to(toMock("result"));
> }
> };
> }
>
>
> Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
>
> > I just pushed a branch called "endpoint-dsl".
> >
> > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > to have a complete and type-safe java DSL for endpoints instead of using
> > URI containing all the parameters. Right now, it compiles but isn't
> really
> > usable at a DSL.
> > I'll get back as soon as I have something which can actually be used so
> > that we can discuss further various options.
> > My rough goal is to be able to write something like:
> >
> > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > .to(mock("result"))
> >
> > instead of
> >
> > from(
> >
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > )
> > .to("mock:result")
> >
> > Stay tuned !
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [HEADS UP] The endpoint-dsl branch
Posted by Guillaume Nodet <gn...@apache.org>.
I think I'm done with a first usable pass at the endpoint DSL.
I've removed the getters/setters, added 2 flavors of fluent methods (one
with the real java type, another one with a String to allow references and
property placeholder processing), renamed the generated classes to
XxxEndpointBuilder and cleaned things a bit.
In order to access this API, one would create an EndpointRouteBuilder
anonymous class instead of the usual RouteBuilder (see below). The only
difference is that it gives immediate access to the fromXxx() and toXxx()
methods that are generated as default methods on the interface, so there's
no need to import anything else.
Please have a look and let me know what you think or if we see anything to
improve.
Cheers,
Guillaume
protected RouteBuilder createRouteBuilder() throws Exception {
return new EndpointRouteBuilder() {
@Override
public void configure() throws Exception {
from(fromFile(start).initialDelay(0).delay(10).move(done +
"/${file:name}"))
.to(toMock("result"));
}
};
}
Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gn...@apache.org> a écrit :
> I just pushed a branch called "endpoint-dsl".
>
> My goal is to experiment with an auto-generated DSL for endpoints, mainly
> to have a complete and type-safe java DSL for endpoints instead of using
> URI containing all the parameters. Right now, it compiles but isn't really
> usable at a DSL.
> I'll get back as soon as I have something which can actually be used so
> that we can discuss further various options.
> My rough goal is to be able to write something like:
>
> from(file("target/data/foo").delay(4000).backoffMultiplier(4
> ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> .to(mock("result"))
>
> instead of
>
> from(
> "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> )
> .to("mock:result")
>
> Stay tuned !
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet