Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.210.52 as permitted sender)
Date: Thu, 21 Feb 2013 21:20:49 +0800
From: Willem jiang <willem.jiang@gmail.com>
To: dev@camel.apache.org
Message-ID: <066312568616451ABA8AB711B82650F3@gmail.com>
In-Reply-To: 
 <CALhQg-Yz-O6325rOkEkVZniiUkx7kYMUhGZw_A7oKz_Q=u96tw@mail.gmail.com>
References: 
 <CALvzYd9gXBdkmrT7E72GvyCTNRxOfT+-9dc2piTd3Ty5ciZ6ug@mail.gmail.com>
 <CALhQg-YgWnSgyvVMPL5U2SXxq0csmUR=YcpDdUX1HiLywq+ngw@mail.gmail.com>
 <A61815750CA046BF8C1E245F69D8FE19@gmail.com>
 <CAGB5yNk0JVTNCb=uZQqHStfSZ1Wng=iVbejBZoZ3TFcaGMHj0A@mail.gmail.com>
 <51258B1E.2010609@gmail.com> <5DCEE02588EF41A5A4F66AF925885DF9@gmail.com>
 <78A42CED-4948-4268-87B3-4BC6D98EE864@code-house.org>
 <CALhQg-Yz-O6325rOkEkVZniiUkx7kYMUhGZw_A7oKz_Q=u96tw@mail.gmail.com>
Subject: Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
 8:00PM CET
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I think the namespace handler are both supported in Spring and Blueprint,=
 we can leverage that to decouple the extended DSL DataModel and Camel co=
re.
One tricky thing is we need to find a way to publish the schemas for the =
extended DSL which could be used for validation. =20


-- =20
Willem Jiang

Red Hat, Inc.
=46useSource is now part of Red Hat
Web: http://www.fusesource.com =7C 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 =20
Weibo: =E5=A7=9C=E5=AE=81willem


On Thursday, =46ebruary 21, 2013 at 7:35 PM, Henryk Konsek wrote:

> > Most popular camel syntaxes do not support extensions by 3rd party el=
ements (I mean Java and XML).
> > Everything then goes directly to core.
> =20
> =20
> =20
> Extending Scala DSL is trivial as Scala provides traits and implicit
> conversions.
> =20
> =20
> As i mentioned already in Java is doable if we deprecate chained
> builder syntax like...
> =20
> from(...).marshal().xstream().to(...)
> =20
> ... in the favor of nested builders and static imports...
> =20
> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
> from(...).marshal(xstream()).to(...);
> =20
> ...and parametrized Data=46ormatDefinition (with static imports for
> syntactic sugar)...
> =20
> import static org.apache.camel.dataformat.XStreamDslBuilder.xstream;
> from(...).marshal(xstream).setXStream(...).to(...);
> =20
> =20
> The bigger issue is the XML DSL syntax. Maybe additional namespace per
> component will solve the issue=3F But I'm not so sure if this approach
> will address our requirements.
> =20
> > Camel core should be separated from DSL.
> > DSL should be built on top of core, not otherwise.
> =20
> =20
> =20
> +1
> =20
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com