Hmmm DSL in pure Java is pants. I have made several attempts, and it may compile but then fail at runtime.
The endChoice is out best option so far. So I am gonna commit that so people can use the CBR with whatever EIPs inside as they want to do. Without this they would have to create new routes and use direct endpoint to link them. On Thu, Feb 17, 2011 at 1:38 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Thanks for the suggestions. I have created a ticket > https://issues.apache.org/jira/browse/CAMEL-3678 > > I managed to get a bit further. I will attach a patch with as far as I will > get. > > You can actually have the code compile, but when you run the Java DSL > fails with a type cast exception when starting. > > However I am running full test now with some improvements to see where > the spots are. > > > > On Thu, Feb 17, 2011 at 12:52 PM, <mitko.ko...@icw.de> wrote: >> Hi Claus, >> >> you do not need to override the to actually, it's my mistake. Your example >> compiles without overriding the "to" method (s) and whatever methods. >> because >> >> extends ProcessorDefinition<Type> >> >> >> gives processor definition the right type. >> >> Regards, >> Mitko >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: >> Claus Ibsen <claus.ib...@gmail.com> >> To: >> dev@camel.apache.org >> Date: >> 17.02.2011 12:36 >> Subject: >> Re: [DISCUSS] - Java DSL caveat with the Content Based Router >> >> >> >> Hi >> >> It is a good idea but do we really dont want to override every methods >> from ProcessorDefinition in all the sub classes, to work around the >> limitations with DSLs in Java? And the implications of keeping the >> code synchronized. >> >> >> >> >> On Thu, Feb 17, 2011 at 11:54 AM, <mitko.ko...@icw.de> wrote: >>> Hello Camel Developers what about this: >>> >>> >>> public class LoadBalanceDefinition<Type extends >> ProcessorDefinition<Type>> >>> extends ProcessorDefinition<Type> { >>> >>> ... >>> >>> public LoadBalanceDefinition<Type> roundRobin() { >>> >>> ... >>> @SuppressWarnings("unchecked") >>> public Type to(String uri) { >>> return (Type) this; >>> } >>> ... >>> >>> >>> } >>> >>> Thus you preserve the type safety and you example works. >>> >>> >>> Regards, >>> Mitko >>> >>> >>> >>> >>> From: >>> Claus Ibsen <claus.ib...@gmail.com> >>> To: >>> dev <dev@camel.apache.org> >>> Date: >>> 17.02.2011 09:49 >>> Subject: >>> [DISCUSS] - Java DSL caveat with the Content Based Router >>> >>> >>> >>> Hi >>> >>> DSL in plain Java is somewhat limited how far you can go with Java and >>> Generics. >>> >>> A common issue over the times has been the Content Based Router where >>> users would use other "complex patterns" inside the when/otherwise >>> blocks. >>> By complex patterns I mean patterns which have additional DSL for >>> configuration. Or for example multicast or load balancer which re-uses >>> the commons DSL's, but under the given mode (eg multicast or load >>> balancing). >>> >>> To indicate when the pattern "ends" you would have to use .end() and >>> the DSL would return back the scope to the previous pattern. But >>> that's not possible, as the Java Generics Type System sucks for doing >>> DSLs. >>> >>> I have been experimenting to see if there was a way to tell in the >>> end, which "scope" to return back to. So in the Content Based Router >>> example, you could indicate: Choice, eg >>> >>> .end(ChoiceDefinition.class) >>> >>> But that doesn't work. >>> So the best solution I have found is as follows: >>> >>> >>> from("direct:start") >>> .choice() >>> .when(body().contains("Camel")) >>> // we need to use endChoice to tell Java >>> DSL to return scope back to the choice DSL >>> >>> .loadBalance().roundRobin().to("mock:foo").to("mock:bar").endChoice() >>> .otherwise() >>> .to("mock:result"); >>> >>> If you don't have .endChoice() then the code above will not compile. >>> >>> >>> By introducing a method named: endChoice, we can force the Java DSL to >>> return back to the CBR scope. >>> >>> Since this problem mostly manifests itself with the Content Based >>> Router, then I think this is the best we can do as far. >>> However do you think endChoice is a good name? It may indicate it ends >>> the entire CBR block? >>> >>> We could also name it >>> - asChoice >>> - endAsChoice >>> - endAndBackToChoice >>> - backToChoice >>> - scopeAsChoice >>> >>> Any good name? >>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: cib...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: davsclaus >>> Blog: http://davsclaus.blogspot.com/ >>> Author of Camel in Action: http://www.manning.com/ibsen/ >>> >>> >>> >>> >>> InterComponentWare AG: >>> Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler >>> Aufsichtsratsvors.: Prof. Dr. Christof Hettich >>> Firmensitz: 69190 Walldorf, Altrottstraße 31 >>> AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516 >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> >> >> >> >> >> InterComponentWare AG: >> Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler >> Aufsichtsratsvors.: Prof. Dr. Christof Hettich >> Firmensitz: 69190 Walldorf, Altrottstraße 31 >> AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516 > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
