Hm, hadn't thought about JAXB. That may be a good way to go. We'd still need to translate the JAXB objects into the CDI metamodel though (probably, unless we created our own impls and had decent namings in the XML).
On Mon, Sep 24, 2012 at 1:41 PM, Matt Benson <[email protected]> wrote: > "If we need" is fine as long as there's no exposed API to deprecate. ;) > > Matt > > On Mon, Sep 24, 2012 at 2:39 PM, Romain Manni-Bucau > <[email protected]> wrote: > > about json/xml jaxb object can be enough, not sure it exists for yaml but > > well no need of weird integration here IMHO > > > > if we want a "new format" we can simply create a new parser...then > refactor > > "if we need" > > > > wdyt? > > > > Romain Manni-Bucau > > Twitter: @rmannibucau > > Blog: http://rmannibucau.wordpress.com/ > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > > > > > > > > > 2012/9/24 Matt Benson <[email protected]> > >> > >> Agreed; I also thought of some kind of approach that would leave the > >> door open but, like you, thought that the basics provided by CDI were > >> to some degree the metamodel we'd be talking about. I wonder if some > >> kind of event handler or pull parsing approach would reduce the work > >> for a given alternate syntax even further. > >> > >> Matt > >> > >> On Mon, Sep 24, 2012 at 1:56 PM, Romain Manni-Bucau > >> <[email protected]> wrote: > >> > +1 > >> > > >> > *Romain Manni-Bucau* > >> > *Twitter: @rmannibucau* > >> > *Blog: > >> > **http://rmannibucau.wordpress.com/*< > http://rmannibucau.wordpress.com/> > >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > >> > > >> > > >> > > >> > > >> > 2012/9/24 Jason Porter <[email protected]> > >> > > >> >> We want to keep DS free of dependencies outside core JDK and Java EE > >> >> deps. > >> >> We could do something like say JSON or YAML, but then we'd end up > >> >> parsing > >> >> that all ourselves. What I think makes the most sense is to create a > >> >> metadata storage of this stuff (or, better, use what CDI already has) > >> >> and > >> >> anyone that wants to create a new parser for a different format can > do > >> >> that. Maybe kick off the parsing early in the bootstrapping and > process > >> >> everything we have back at a later phase. > >> >> > >> >> Thoughts? > >> >> > >> >> On Mon, Sep 24, 2012 at 12:43 PM, Matt Benson <[email protected]> > >> >> wrote: > >> >> > >> >> > Here's a random thought: would any other format be better than XML > >> >> > for what is effectively describing CDI annotations? :) > >> >> > > >> >> > Matt > >> >> > > >> >> > On Mon, Sep 24, 2012 at 12:11 PM, Jason Porter > >> >> > <[email protected]> > >> >> > wrote: > >> >> > > I haven't heard anything for 15 days on this. Seems like it's > safe > >> >> > > to > >> >> > take > >> >> > > this and put it up on the wiki and get started. > >> >> > > > >> >> > > On Wed, Sep 19, 2012 at 12:17 AM, Romain Manni-Bucau > >> >> > > <[email protected]>wrote: > >> >> > > > >> >> > >> For me that's almost all, wonder about: > >> >> > >> > >> >> > >> 1) xml? Shouldnt we discuss about it when this thread will be > >> >> > >> done? > >> >> > >> 2) do we want it extensible to let the user add 'shortcuts' > >> >> > (webservices, > >> >> > >> camel context...)? > >> >> > >> Le 19 sept. 2012 00:09, "Jason Porter" <[email protected]> > a > >> >> > écrit : > >> >> > >> > >> >> > >> > Let's start listing requirements and use cases for what we > want > >> >> > >> > the > >> >> > XML > >> >> > >> > config module to do. I know I have heard of two: > >> >> > >> > > >> >> > >> > 1) Bean configuration and wiring to allow another integration > >> >> > >> > point > >> >> > with > >> >> > >> > CDI for things such as Drools or other projects which may not > be > >> >> > directly > >> >> > >> > configured via Java > >> >> > >> > 2) Applying changes to beans such as interceptors to a wide > >> >> > >> > range of > >> >> > >> > classes via a matched regex (Mark, we'll need your use case > >> >> > >> > here) > >> >> > >> > > >> >> > >> > What else do people have? > >> >> > >> > > >> >> > >> > -- > >> >> > >> > Jason Porter > >> >> > >> > http://lightguard-jp.blogspot.com > >> >> > >> > http://twitter.com/lightguardjp > >> >> > >> > > >> >> > >> > Software Engineer > >> >> > >> > Open Source Advocate > >> >> > >> > Author of Seam Catch - Next Generation Java Exception Handling > >> >> > >> > > >> >> > >> > PGP key id: 926CCFF5 > >> >> > >> > PGP key available at: keyserver.net, pgp.mit.edu > >> >> > >> > > >> >> > >> > >> >> > > > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > Jason Porter > >> >> > > http://lightguard-jp.blogspot.com > >> >> > > http://twitter.com/lightguardjp > >> >> > > > >> >> > > Software Engineer > >> >> > > Open Source Advocate > >> >> > > Author of Seam Catch - Next Generation Java Exception Handling > >> >> > > > >> >> > > PGP key id: 926CCFF5 > >> >> > > PGP key available at: keyserver.net, pgp.mit.edu > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Jason Porter > >> >> http://lightguard-jp.blogspot.com > >> >> http://twitter.com/lightguardjp > >> >> > >> >> Software Engineer > >> >> Open Source Advocate > >> >> Author of Seam Catch - Next Generation Java Exception Handling > >> >> > >> >> PGP key id: 926CCFF5 > >> >> PGP key available at: keyserver.net, pgp.mit.edu > >> >> > > > > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
