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/

Reply via email to