We have implementation of SCA parser based on DOM api [1]. As long as Spring or Blueprint allows to access document does it will work [2]. Not sure if JAXB will be capable to handle that and last thing I would like to see is hand written mapping between elements and DSL representations. The main problem with Spring/Aries are multiple schema locations. Both expects only one. This impiles creation of composite schemas which imports all others [3]. As long as Catalog/Schema resolver is able to follow include and import statements it should work. Someone just need experiment. ;-)
[1] https://github.com/jboss-switchyard/core/tree/master/config/src/main/java/org/switchyard/config/model/composite [2] http://static.springsource.org/spring/docs/2.0.x/reference/extensible-xml.html#extensible-xml-parser [3] https://github.com/jboss-switchyard/core/blob/master/config/src/main/resources/org/oasis-open/docs/ns/opencsa/sca/200912/sca-1.1-cd06.xsd Cheers, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org > On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <l...@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.ji...@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.ji...@gmail.com(mailto: >> willem.ji...@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: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/
