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: v0.4-incubating adding Seam Config (xml config)
Date Mon, 09 Jul 2012 09:29:09 GMT
for me a separate module sounds logical but nothing blocks to make it part
of the core since each extension can be activated using
configsourceproviders of DS

- Romain


2012/7/9 Pete Muir <pmuir@redhat.com>

> As Romain said, I would expect you to need to turn this on somehow (e.g.
> enable extension). If we think a separate module is the easiest way to turn
> it on, then I think that makes sense.
>
> On 9 Jul 2012, at 10:20, Mark Struberg wrote:
>
> > The main reason why I would prefer a separate module is that this is
> really only used by a few people. And those really get less and less. Most
> people do not use it and would just be hit by a huge scanning effort. Maybe
> we could make this better performing, but it certainly adds quite some
> complexity.
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Pete Muir <pmuir@redhat.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Saturday, July 7, 2012 12:33 PM
> >> Subject: Re: v0.4-incubating adding Seam Config (xml config)
> >>
> >> +1 to adding it from me.
> >>
> >> XML config is probably the feature (as opposed to enhancement to
> existing
> >> feature or "bug" fix) most requested for CDI. I think we need
> >> something like this in DeltaSpike, in order to fulfil our goals.
> >>
> >> A non compiled format such as XML (or YAML or ...) makes a lot of sense
> for
> >> *configuration* of an application (as opposed to wiring [1]),
> >>
> >> As Jason said, this is the only known XML config (dialect and impl) for
> CDI, so
> >> I think it's quite uncontroversial. The "API" of the config is
> >> actually the XML dialect, which has received a lot of attention in the
> past
> >> (designed for CDI 1.0, so fully reviewed by the EG).
> >>
> >> BTW I'm not understanding why putting it in a separate module makes a
> >> difference? It's dependencies are basically zero (CDI API and SAX,
> which is
> >> in the JDK), and I think if it goes in it's own package, it shouldn't
> >> cause contention on class files. Personally, I think this is a core
> concern, and
> >> as it doesn't introduce dependencies can go easily into the core.
> >>
> >> On 6 Jul 2012, at 21:14, Romain Manni-Bucau wrote:
> >>
> >>> +0 since i'm not sure XML is really CDI spirit...and it needs to be
> >>> consistent with already existing config (global alternatives etc)
> which can
> >>> be a bit complicated
> >>>
> >>> - Romain
> >>>
> >>>
> >>> 2012/7/6 Gerhard Petracek <gerhard.petracek@gmail.com>
> >>>
> >>>> i'm not sure if we should start with it for v0.4, however, if it
> >> gets an
> >>>> own (optional) module: +0
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2012/7/6 Jason Porter <lightguard.jp@gmail.com>
> >>>>
> >>>>> It's been a 10 on our list for awhile but we haven't done
> >> it yet.
> >>>> Thoughts
> >>>>> on adding it to v0.4? It would be a straight port from what we have
> >> in
> >>>> Seam
> >>>>> 3 with package name changes. It's currently the only
> >> implementation in
> >>>>> existence (that we know of) of the older xml config that was to
be
> >> part
> >>>> of
> >>>>> spec but was later pulled.
> >>>>>
> >>>>> --
> >>>>> 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