camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Thoughs on the camel dsl for 2.x
Date Sun, 07 Jun 2009 08:55:07 GMT
Hi Harian,

how about generating the dsl from maven inside the userĀ“s project. Each 
camel module that is referenced could offer extensions to the DSL. Then 
in the generate sources phase a DSL could be constructed that includes 
all camel and even user modules that contribute to the DSL. I think this 
late DSL generation is the only way to bring extensibility to Java 
Fluent Builders. I am not so sure about the disadvantages of this attempt.



Hadrian Zbarcea schrieb:
> Camel has this wonderful discovery mechanism for RouteBuilders, 
> TypeConverters, Languages, etc. so if one uses Camel she only needs to 
> write her code, drop it somewhere on the classpath and... everything 
> works.
> The only main thing that's not really pluggable is the DSL.  The 
> concept of a DSL supported for multiple languages is unique to Camel 
> afaik and quite a powerful one.  However:
> * it is hand-crafted and this led to quite a few inconsistencies 
> between java, xml, scala, etc.
> * the dsl is not supported in a few languages yet, such as python, 
> ruby (expressions are supported though)
> * the ProcessorType has become huge
> * it's increasingly difficult/annoying to add support for a new 
> pattern, because this changes the API
> * does not support user-defined pattern, a user is pretty much stuck 
> with using a processor or bean, but cannot extend the language
> * does not support alternate dsl(s) in the same language, such as 
> java.  The processors are very powerful, and one could envision using 
> a different language (say something like bpel), to assemble them and 
> get the desired behavior.
> I think the biggest hurdle is I think the fact that we must support 
> smart completion in the ide(s) and java is not a dynamic language.  I 
> would like to investigate the idea of patterns being *described* in a 
> language (such as xml, or some other grammar) and then generate the 
> dsl.  I think it should be feasible, based on the fact that there are 
> not many concepts needed to describe a pattern (as a black box) and 
> the generated dsl could be built once (maybe packaged as a separate 
> jar) and reused.
> Your thoughts highly appreciated.
> Hadrian


Christian Schneider

View raw message