Have not thought about JAXB neither. It could be neat to have. Otoh it sounds a bit weird to add an abstraction for an abstraction...
LieGrue, strub ----- Original Message ----- > From: Jason Porter <[email protected]> > To: [email protected]; [email protected] > Cc: Romain Manni-Bucau <[email protected]> > Sent: Monday, September 24, 2012 9:54 PM > Subject: Re: XML Config requirements > > 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 >
