I think the namespace handler are both supported in Spring and Blueprint, we can leverage that to decouple the extended DSL DataModel and Camel core. One tricky thing is we need to find a way to publish the schemas for the extended DSL which could be used for validation.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Thursday, February 21, 2013 at 7:35 PM, Henryk Konsek wrote: > > Most popular camel syntaxes do not support extensions by 3rd party elements > > (I mean Java and XML). > > Everything then goes directly to core. > > > > Extending Scala DSL is trivial as Scala provides traits and implicit > conversions. > > > As i mentioned already in Java is doable if we deprecate chained > builder syntax like... > > from(...).marshal().xstream().to(...) > > ... in the favor of nested builders and static imports... > > import static org.apache.camel.dataformat.XStreamDslBuilder.*; > from(...).marshal(xstream()).to(...); > > ...and parametrized DataFormatDefinition (with static imports for > syntactic sugar)... > > import static org.apache.camel.dataformat.XStreamDslBuilder.xstream; > from(...).marshal(xstream).setXStream(...).to(...); > > > The bigger issue is the XML DSL syntax. Maybe additional namespace per > component will solve the issue? But I'm not so sure if this approach > will address our requirements. > > > Camel core should be separated from DSL. > > DSL should be built on top of core, not otherwise. > > > > +1 > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com
