camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Date Thu, 21 Feb 2013 11:47:56 GMT
On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <luke@code-house.org>wrote:

> Keeping DSL syntax in core is caused by current design. Most popular camel
> syntaxes do not support extensions by 3rd party elements (I mean Java and
> XML). Everything then goes directly to core. That's wrong, that's really
> bad. DSL should allow pluging new functors without problems. I mentioned
> substitution group as desired design in XML Schema which will let us use
> extensions.
>

Do you have any example of extensions working for spring or blueprint ?  I
can't find any good example from the top of my head, so I'm not even sure
that it can actually be implemented (not from an xml perspective, but from
a spring or blueprint one).


>
> To be honest, does camel-core care which dataformat is configured how?
> Currently yes, however some of us already know it's not necessary. Camel
> core should be separated from DSL. DSL should be built on top of core, not
> otherwise.
>
> Cheers,
> Lukasz
>
> Wiadomość napisana przez Willem jiang <willem.jiang@gmail.com> w dniu 21
> lut 2013, o godz. 04:06:
>
> > I think multiple DSL suppport is most important feature for Camel, as
> our competitor just only support one or none of them.
> >
> > We got the some complains from the user that why does the Java DSL work,
> but the Spring DSL doesn't work. They treat it a bug not a small syntactic
> failure.
> >
> > It could be more easy if we can maintain the core module code in one
> place. When you add no data format, you need to remember to update the
> module class.
> >
> > BTW, We have lots of tests in Camel to make sure the Java DSL, Spring
> DSL and other DSL do they job righty.
> >
> > --
> > 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 10:49 AM, Hadrian Zbarcea wrote:
> >
> >> I strongly disagree. On what are you basing your "MUST" statement?
> >>
> >> There are 2 areas in which camel excels: one is the middleware
> >> abstraction, via the api. The second is the runtime mediation. The dsl
> >> has nothing to do with either, it's just syntactic sugar, eye candy. I
> >> don't deny that it's helpful especially if well thought out. But I
> >> certainly wouldn't go that far to state that there must be one
> >> authoritative source.
> >>
> >> Cheers
> >> Hadrian
> >>
> >>
> >> On 02/16/2013 03:48 AM, Claus Ibsen wrote:
> >>> On Sat, Feb 16, 2013 at 9:43 AM, Willem jiang <willem.jiang@gmail.com(mailto:
> willem.jiang@gmail.com)> wrote:
> >>>> Hi Henryk,
> >>>>
> >>>> The static import of Builder method could resolve the dependency
> problem of Java DSL.
> >>>> But when we move to the Spring XML or Blueprint, we still need a
> DataFormat model to hold the reference in the camel-core.
> >>>
> >>>
> >>>
> >>> Yes there MUST be one authoritative source of the DSL which is the
> >>> classes in the model package of camel-core.
> >>> This model is then used to fully automatic generate the XML DSLs for
> >>> spring and blueprint. This ensures we have a DSL that is in sync.
> >>>
> >>>
> >>>> --
> >>>> 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 14, 2013 at 4:02 AM, Henryk Konsek wrote:
> >>>>
> >>>>>> This was the today's discussion on IRC (irc://
> irc.codehaus.org/camel (http://irc.codehaus.org/camel)).
> >>>>>
> >>>>>
> >>>>>
> >>>>> You seem to have a nice party here :) . I must join the next week.
> >>>>>
> >>>>> @Hadrian:
> >>>>> SCXML component is something I wanted for Camel for a really long
> >>>>> time. I like the library very much and it would be great to have
it
> in
> >>>>> Camel. I'm glad you want to give it a chance.
> >>>>>
> >>>>> Regarding the Camel Core and DSLs - it would be great to move
> >>>>> component-related DSL definitions from the core. For example XStream
> >>>>> data format definition
> >>>>> (org.apache.camel.model.dataformat.XStreamDataFormat) should be
kept
> >>>>> in the camel-xstream jar and somehow dynamically included in the
DSL.
> >>>>> I'm considering something similar to the the following snippet:
> >>>>>
> >>>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
> >>>>> ...
> >>>>> from(...).marshal(xstream()).to(...);
> >>>>>
> >>>>> or even
> >>>>>
> >>>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
> >>>>> ...
> >>>>> from(...).marshal(xstream).setXStream(...).to(...);
> >>>>>
> >>>>>
> >>>>> In general static imports would be our friends here :) .I need to
> >>>>> think about it and then I'll come with a concrete proposal.
> >>>>>
> >>>>> See you on the next IRC session (hopefully).
> >>>>>
> >>>>> --
> >>>>> Henryk Konsek
> >>>>> http://henryk-konsek.blogspot.com
> >>>>
> >>>
> >>
> >
> >
> >
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message