Hello Everyone,
@Sebastian: maybe you could take a look at the Open eHealth integration
Platform (named IPF). It has a Groovy DSL that extends the Camel Java DSL.
Here is a link to get started
http://repo.openehealth.org/confluence/display/ipf2/Core+features#Corefeatures-Scriptinglayer
. If you use the IPF Groovy DSL in IDEA you can even have auto
completion, and type safety. If you have questions regarding IPF DSL, you
may use the IPF user mailing lists.
I am also tying to find a solution to change the Camel Java DSL
implementation so that it allows extension.In general my approach is
simple: Extend RouteBuilder, make it return My RouteDefinition with my
extensions.
public abstract class MyRouteBuilder extends RouteBuilder {
...
@Override
public MyRouteBuilder from(String uri) {
return (MyRouteDefinition) super.from(uri);
}
...
}
public class MyRouteDefinition extends RouteDefinition {
...
public MyRouteDefinition noStreamCaching() {
return (MyRouteDefinition) super.noStreamCaching();
}
...
}
public class RouteDefinition extends ProcessorDefinition<RouteDefinition>
{
...
public RouteDefinition noStreamCaching() {
setStreamCache("false");
StreamCaching.noStreamCaching(getInterceptStrategies());
return this;
}
...
}
There is one problem with this: currently rhe RouteDefinition class "does
not allow" DSL extension ( because RouteBuilder.noStreamCaching() returns
type RouteDefinition). This is so, because if you extends RouteDefinition,
and you use streamCaching() you loose the type of your extension, so you
won't be able to see your extensions in the IDE after streamCaching().
This is not the case when you look at ProcessorDefinition, which
RouteDefinition extends. ProcessorDefinition is declared as:
public abstract class ProcessorDefinition<Type extends
ProcessorDefinition<Type>> ... {
...
public Type to(String uri) {
}
...
}
Note that, the class ProcessorDefinition "allows" DSL extensions, because
it returns the generic Type, while RouteDefinition does not allow such
extensions.
If I come up with a simple solution, that does not invove a lot of
refactoring and duplication, I will write. If I do not find such
solution I will post my results anyway.
Regards,
Mitko
From:
James Strachan <[email protected]>
To:
[email protected]
Date:
10.02.2011 13:13
Subject:
Re: How to extend the Spring DSL ?
Sent by:
[email protected]
On 10 February 2011 11:25, sebastien.petrucci
<[email protected]> wrote:
>
> Thank you for your answer.
>
> I just would like to better explain what I'm doing.
>
> I work on a product which is an integration platform for the financial
> world. This product is used in some banks and coporates. Our product is
> built on top of another commercial ESB, for which we provide a number of
> specific extensions (custom connectors, message validation, statefull
> routing ...)
> As we want to rethink our product and move away from our current ESB,
I'm
> currently evaluating the various solutions available on the market. So
far,
> I've seen some of the bigger products (like Oracle SOA) as well as lower
> level integration frameworks like Apache Camel or Spring Integration.
>
> To me, Camel has some trully some valuable assets ... the most important
> being its simple and intuitive (java or XML) DSL. It really brings an
added
> value on multiple levels (dev, clarity, supportability, learning curve,
> ....) that the other solutions don't have.
> I truly thing that, it would be a KILLER FEATURE to make the DSL somehow
> extendable.
> That would allow users to wrap their custom components and expose them
as
> verbs, directly in the DSL ! This way, you can specialize Camel to suit
your
> needs, preferred practices and components, ... in an elegant way. To my
> knowledge, nobody on the market proposes that !
>
> Please consider this as a possible enhencement for the future of Camel.
>
> In the meantime, I will continue my attempts to extend the Spring XML
DSL
> without impacting camel-spring.
Note that there's nothing to stop you having custom DSLs outside of
Camel's core. Making an extensible Java + XML + Scala DSL is gonna be
hard (e.g. XSD pain) and quickly loses the value proposition of the
DSL since for tooling a DSL must be static; but its easy right now to
extend those (making new XSDs importing Camel's XSD, or deriving from
the Java builders etc). This is how we do Camel BAM today...
http://camel.apache.org/bam.html
Though its worth questioning, do you really want new verbs or nouns?
Often folks want to drop in their own components into Camel; wrap up
some service or functionality as a black box then route into it or
from it with standard Camel; for this the Camel Component / Endpoint
abstraction seems a perfect fit.
Its very trivial to make something which acts as a regular Camel
Component; you've then logical names or 'verbs' for the individual
endpoints/ports/features the component supports. You can then use
regular Camel DSL to send events/messages into or out of any part of
the component; so you can easily extend vanilla Camel to add any kind
of service or feature; so long as you can represent it as a bean or
endpoint.
e.g. in your example you could do...
<route>
<from uri="..." />
<to uri="mycompany:semantic-validation/somePackage"/>
<to uri="...">
</route>
--
James
-------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/
Open Source Integration
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
