deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: XML Config requirements
Date Mon, 24 Sep 2012 22:36:00 GMT
oh, java is an abstraction for bytecode which is an abstraction ....we can
add abstraction at this level ;)



*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*




2012/9/25 Mark Struberg <struberg@yahoo.de>

> 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 <lightguard.jp@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; gudnabrsam@gmail.com
> > Cc: Romain Manni-Bucau <rmannibucau@gmail.com>
> > 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 <gudnabrsam@gmail.com>
> 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
> >>  <rmannibucau@gmail.com> 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 <gudnabrsam@gmail.com>
> >>  >>
> >>  >> 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
> >>  >> <rmannibucau@gmail.com> 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 <lightguard.jp@gmail.com>
> >>  >> >
> >>  >> >> 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
> > <gudnabrsam@gmail.com>
> >>  >> >> 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
> >>  >> >> > <lightguard.jp@gmail.com>
> >>  >> >> > 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
> >>  >> >> > > <rmannibucau@gmail.com>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" <lightguard.jp@gmail.com>
> >>  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
> >
>

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