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
