camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: DSL progress
Date Mon, 08 Sep 2008 19:23:42 GMT
2008/9/6 Vadim Chekan <>:
> James Strachan wrote:
>> Awesome! :)
>> Did you try out the xtext stuff to generate a nice context
>> highlighting editor as well?
>>> At the moment I use *Type classes but I'm working on injecting routes
>>> directly into camel context now.
>> Creating the *Type classes sounds good btw - the classes in
>> org.apache.camel.model; then we can just add the RoutesType to the
>> CamelContext and share the same code to take the AST and turn it into
>> the actual running routes. Is that kinda what you meant?
> No I haven't look at xtext yet. The next task on my plate is When it's done
> I'll start hacking eclipse.
> Type classes. Well, my idea was to avoid their usage and inject concrete
> route objects into the camel context directly. Just for sake of avoiding
> extra dependencies.
> But after some more code reading I discovered that a lot of business is done
> in Type classes. Wrapping routes into exception handlers, hooking up
> interceptors, etc.
> So I decided I will use Type classes.

Great stuff; if nothing else it should hopefully help you get started
and not have to worry about the internal details on how the patterns
work etc.

> I could experiment with implementing
> this logic in parser itself, but why would I do something that already is
> implemented? BTW, it is not rhetorical question so if there is a reason, let
> me know :)

It'd certainly help if all the DSLs shared the same AST - the model
objects; rather than having lots of different ways to turn the AST
into the actual runtime objects. I'm sure the AST could be improved
some; its a tad complex to read as its also implemented as JAXB beans
so that the AST can be faithfully round tripped to and from XML.

> Overall it turned out to be much simpler task then I anticipated. Kudos to
> antlrworks. This tool changed my opinion about LL parsers (top-to-down
> parser). I am ready to trade LR parser for what this tool gives to you.
> Ability to debug your *grammar* even before you compile it with the
> application saves tons of time and is just fun to watch and play with.
> And when it shows a visual graph with conflicting choices in the grammar...
> man, I was just speechless when I discovered it.


The eclipse plugin is pretty good too btw!

> Questions:
> Here's what I'm considering as I'm doing it. First of all some kind of code
> reusage support. What if you have the same route definition in several
> places? Do we want to support some kind of macro?
> If we do, then the next thing users will ask is "I have a macro, but in each
> application I need to set a parameter in it, for example queue name". As I'm
> trying to keep domain of this DSL small and avoid yet another interpreter.
> So I think it'd be beneficial to integrate this DSL with scripting languages
> which we already have in camel.

Having a macro sounds good; i guess a macro with defined parameters
then folks can instantiate them.

Maybe something that looks a bit like a method call?

def foo(a, b) {
  if (xpath("/foo/bar")) {
    to a
  else {
    to b

// then later on in some route

route from "activemq:Foo"
  foo("activemq:Cheese", "file://something")
  foo("activemq:Bar", "file://whatnot")

> Another thing is that we need external calls in order to implement
> conditions. I'd rather delegate expressions evaluation and keep DSL a
> routing only language.
> For example dsl:
> route from {
>        // must return list of strings or null
>        // TODO: where getMySourceList is declared???
>        juel:getMySourceList('InputQueue', 'Integration')
> } to {
>        'mock:a1'
>        if(javascript('headers.header["a"] == "b"')) {
>                'a2'
>        } else {
>                multicast {
>                        'a3'
>                        'a4'
>                }
>        }
> }
> Comments are more than welcome,
> Vadim.
> P.S. Here is the current parser. There is a decision conflict around "else"
> and I'm working on it.

Looks great! :)

Open Source Integration

View raw message