Re: Config rework, take 2

[Romain Manni-Bucau]

Pushed eveything I had and created the related jira for 1.8.0.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2016-11-08 21:28 GMT+01:00 Romain Manni-Bucau :

> Le 8 nov. 2016 18:59, "John D. Ament"  a écrit :
> >
> > I'm personally fine with that as a first pass but agree its going to
> cause
> > some issues because config is available pre-initialization of container
> > (e.g. there maybe no CDI available yet) as a result converters, filters
> may
> > not work.  Something to resolve at a later point.
> >
>
> The use case is runtime config - extension config being considered there
> as internal config or the app which can be hardcoded.
>
> I ll wait until tomorrow and if nobody shout will create tickets and push
> on master.
>
> > John
> >
> > On Tue, Nov 8, 2016 at 12:57 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > @ConfigProperty(converter) method was added and ConfigSource and
> > > ConfigFilter decoarated with @Source and @Filter are added to the
> config
> > > using cdi bean lookup after extension startup (= usable after CDI
> startup
> > > but without any META-INF/services and with all CDI features like
> injections
> > > and interceptors)
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | JavaEE Factory
> > > 
> > >
> > > 2016-11-08 18:52 GMT+01:00 John D. Ament :
> > >
> > > > What's currently on your branch? I saw proxy.  Anything else?
> > > >
> > > > John
> > > >
> > > > On Tue, Nov 8, 2016 at 12:46 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > if i open 3 tickets (convert, proxy, cdi source/filter) then push
> my
> > > > branch
> > > > > does it work?
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | JavaEE
> Factory
> > > > > 
> > > > >
> > > > > 2016-11-08 18:43 GMT+01:00 John D. Ament :
> > > > >
> > > > > > On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > 2016-11-07 17:56 GMT+01:00 Mark Struberg
>  > > > >:
> > > > > > >
> > > > > > > > yes the EAR case is a bit harder. Also OSGi is a bit tricky.
> > > > > > > >
> > > > > > > > In my javaconfig proposal I have moved this out into a SPI
> which
> > > is
> > > > > > > > pluggable.
> > > > > > > > The only requirement is that you can get the config for 'your
> > > > > > > application'
> > > > > > > > via ConfigProvider#getConfig().
> > > > > > > >
> > > > > > > > If this is internally done via a Map or
> a
> > > > > > > > Map or via a ThreadLocal is totally
> up
> > > to
> > > > > the
> > > > > > > > implementation. For OSGi the ClassLoader might not be as
> good as
> > > > in a
> > > > > > WAR
> > > > > > > > or EAR. The ThreadLocal might blow up in an EAR on various
> > > > > containers,
> > > > > > > etc.
> > > > > > > > I fear there is no one-fits-all solution. We might provide an
> > > impl
> > > > > > which
> > > > > > > > can be configured to use different strategies.
> > > > > > > >
> > > > > > > > The question is whether we like to make it depending on CDI
> or if
> > > > it
> > > > > > > > should also work purely in SE.
> > > > > > > >
> > > > > > > >
> > > > > > > I'd say this one is easy for deltaspike if we re-read the
> project
> > > > > > proposal
> > > > > > > (and BTW should be the same under EE ecosystem now, other
> choices
> > > > don't
> > > > > > > make much sense now in particuar for the config which should be
> > > > > > > contextualized by something else than itself - ok off topic
> ;)).
> > > > > > >
> > > > > > > Concretely how do we move forward on these topics? I'm
> concerned to
> > > > get
> > > > > > > converter method in @ConfigProperty, the @Source/@Filter
> detection
> > > > and
> > > > > > > proxy support. Other mentionned features can be put on a
> backlog or
> > > > > > > forgotten I wouldn't cry.
> > > > > > >
> > > > > > >
> > > > > > That's actually why i was saying separate JIRA tickets.  Tackle
> the

Re: Config rework, take 2

[Romain Manni-Bucau]

@ConfigProperty(converter) method was added and ConfigSource and
ConfigFilter decoarated with @Source and @Filter are added to the config
using cdi bean lookup after extension startup (= usable after CDI startup
but without any META-INF/services and with all CDI features like injections
and interceptors)


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2016-11-08 18:52 GMT+01:00 John D. Ament :

> What's currently on your branch? I saw proxy.  Anything else?
>
> John
>
> On Tue, Nov 8, 2016 at 12:46 PM Romain Manni-Bucau 
> wrote:
>
> > if i open 3 tickets (convert, proxy, cdi source/filter) then push my
> branch
> > does it work?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2016-11-08 18:43 GMT+01:00 John D. Ament :
> >
> > > On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > 2016-11-07 17:56 GMT+01:00 Mark Struberg  >:
> > > >
> > > > > yes the EAR case is a bit harder. Also OSGi is a bit tricky.
> > > > >
> > > > > In my javaconfig proposal I have moved this out into a SPI which is
> > > > > pluggable.
> > > > > The only requirement is that you can get the config for 'your
> > > > application'
> > > > > via ConfigProvider#getConfig().
> > > > >
> > > > > If this is internally done via a Map or a
> > > > > Map or via a ThreadLocal is totally up to
> > the
> > > > > implementation. For OSGi the ClassLoader might not be as good as
> in a
> > > WAR
> > > > > or EAR. The ThreadLocal might blow up in an EAR on various
> > containers,
> > > > etc.
> > > > > I fear there is no one-fits-all solution. We might provide an impl
> > > which
> > > > > can be configured to use different strategies.
> > > > >
> > > > > The question is whether we like to make it depending on CDI or if
> it
> > > > > should also work purely in SE.
> > > > >
> > > > >
> > > > I'd say this one is easy for deltaspike if we re-read the project
> > > proposal
> > > > (and BTW should be the same under EE ecosystem now, other choices
> don't
> > > > make much sense now in particuar for the config which should be
> > > > contextualized by something else than itself - ok off topic ;)).
> > > >
> > > > Concretely how do we move forward on these topics? I'm concerned to
> get
> > > > converter method in @ConfigProperty, the @Source/@Filter detection
> and
> > > > proxy support. Other mentionned features can be put on a backlog or
> > > > forgotten I wouldn't cry.
> > > >
> > > >
> > > That's actually why i was saying separate JIRA tickets.  Tackle the
> > complex
> > > needed stuff now, work on the more polish stuff later.
> > >
> > > Obviously, deltaspike should be focused on CDI runtimes.
> > >
> > >
> > > >
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Monday, 7 November 2016, 12:44, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com> wrote:
> > > > > > > added @Source and @Filter as markers (was breaking applications
> > > > > otherwise),
> > > > > > pushed the basic plain proxying too. Only tested with OWB for now
> > but
> > > > > seems
> > > > > > not bad.
> > > > > >
> > > > > > The storage change is more impacting cause of ear case which is
> not
> > > > > > protable at all so wonder if we can do anything about it without
> > > > breaking
> > > > > > existing applications. Maybe we should just ensure we don't leak
> > the
> > > > > > classloader as key for now to not break anyone (we can leak if
> CDI
> > > > > doesn't
> > > > > > finish to start and the application is undeployed AFAIK).
> > > > > >
> > > > > > Adding the ConfigResolver as an instance in the CDI context (= a
> > > bean)
> > > > is
> > > > > > still an option IMHO but can wait and is more an internal
> > refactoring
> > > > > than
> > > > > > an API work.
> > > > > >
> > > > > > wdyt? What would be the next steps? JIRA for converter method,
> > proxy
> > > > > > feature and source/filter detection in CDI?
> > > > > >
> > > > > > Happy to also get some help on running it on other containers.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Blog
> > > > > > 

Re: Config rework, take 2

[John D. Ament]

On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau 
wrote:

> 2016-11-07 17:56 GMT+01:00 Mark Struberg :
>
> > yes the EAR case is a bit harder. Also OSGi is a bit tricky.
> >
> > In my javaconfig proposal I have moved this out into a SPI which is
> > pluggable.
> > The only requirement is that you can get the config for 'your
> application'
> > via ConfigProvider#getConfig().
> >
> > If this is internally done via a Map or a
> > Map or via a ThreadLocal is totally up to the
> > implementation. For OSGi the ClassLoader might not be as good as in a WAR
> > or EAR. The ThreadLocal might blow up in an EAR on various containers,
> etc.
> > I fear there is no one-fits-all solution. We might provide an impl which
> > can be configured to use different strategies.
> >
> > The question is whether we like to make it depending on CDI or if it
> > should also work purely in SE.
> >
> >
> I'd say this one is easy for deltaspike if we re-read the project proposal
> (and BTW should be the same under EE ecosystem now, other choices don't
> make much sense now in particuar for the config which should be
> contextualized by something else than itself - ok off topic ;)).
>
> Concretely how do we move forward on these topics? I'm concerned to get
> converter method in @ConfigProperty, the @Source/@Filter detection and
> proxy support. Other mentionned features can be put on a backlog or
> forgotten I wouldn't cry.
>
>
That's actually why i was saying separate JIRA tickets.  Tackle the complex
needed stuff now, work on the more polish stuff later.

Obviously, deltaspike should be focused on CDI runtimes.


>
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > > On Monday, 7 November 2016, 12:44, Romain Manni-Bucau <
> > rmannibu...@gmail.com> wrote:
> > > > added @Source and @Filter as markers (was breaking applications
> > otherwise),
> > > pushed the basic plain proxying too. Only tested with OWB for now but
> > seems
> > > not bad.
> > >
> > > The storage change is more impacting cause of ear case which is not
> > > protable at all so wonder if we can do anything about it without
> breaking
> > > existing applications. Maybe we should just ensure we don't leak the
> > > classloader as key for now to not break anyone (we can leak if CDI
> > doesn't
> > > finish to start and the application is undeployed AFAIK).
> > >
> > > Adding the ConfigResolver as an instance in the CDI context (= a bean)
> is
> > > still an option IMHO but can wait and is more an internal refactoring
> > than
> > > an API work.
> > >
> > > wdyt? What would be the next steps? JIRA for converter method, proxy
> > > feature and source/filter detection in CDI?
> > >
> > > Happy to also get some help on running it on other containers.
> > >
> > >
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github
> > >  |
> > > LinkedIn  | JavaEE Factory
> > > 
> > >
> > > 2016-11-07 9:39 GMT+01:00 Romain Manni-Bucau :
> > >
> > >>  In the spirit of sharing and trying to move forward I started a
> branch
> > on
> > >>  my github fork: https://github.com/rmannibucau/deltaspike/tree/
> > >>  fb/config-rework
> > >>
> > >>  For now it includes 1 ("easy") and 5 (pre 2 storage but will be
> > > part of
> > >>  the refactoring "2" normally since we'll not break this API).
> > >>
> > >>  About 5 there is the question of the detection. By type is enough
> > >>  technically but wonder if we should introduce @Source and @Filter
> just
> > as
> > >>  markers to ensure we don't also detect SPI sources and filters which
> > > are
> > >>  likely CDI beans in a lot of apps.
> > >>  Feedback welcomed ^^ :).
> > >>
> > >>  Once done, next step will be to add 3 then try to do 2. If all is
> good
> > we
> > >>  can work on the jira tickets.
> > >>
> > >>
> > >>
> > >>  Romain Manni-Bucau
> > >>  @rmannibucau  |  Blog
> > >>   | Old Blog
> > >>   | Github
> > >>   | LinkedIn
> > >>   | JavaEE Factory
> > >>  
> > >
> > >>
> > >>  2016-11-06 21:40 GMT+01:00 Mark Struberg  >:
> > >>
> > >>>  +1 for moving the Config out into an own module. It's the best we
> > > can do
> > >>>  for now. The JSR will likely take a bit to evolve and until then we
> > can
> > > use
> > >>>  what we have in DeltaSpike. Just a bit cleaned up.
> > >>>
> > >>>  LieGrue,
> > >>>  strub
> > >>>
> > >>>
> > >>>  PS: a single ticket is by far enough imo.
> > >>>
> > >>>
> > >>>
> > >>>
> 

Re: Config rework, take 2

[Mark Struberg]

yes the EAR case is a bit harder. Also OSGi is a bit tricky.

In my javaconfig proposal I have moved this out into a SPI which is pluggable.
The only requirement is that you can get the config for 'your application' via 
ConfigProvider#getConfig().

If this is internally done via a Map or a 
Map or via a ThreadLocal is totally up to the 
implementation. For OSGi the ClassLoader might not be as good as in a WAR or 
EAR. The ThreadLocal might blow up in an EAR on various containers, etc. I fear 
there is no one-fits-all solution. We might provide an impl which can be 
configured to use different strategies.

The question is whether we like to make it depending on CDI or if it should 
also work purely in SE.


LieGrue,
strub




> On Monday, 7 November 2016, 12:44, Romain Manni-Bucau  
> wrote:
> > added @Source and @Filter as markers (was breaking applications otherwise),
> pushed the basic plain proxying too. Only tested with OWB for now but seems
> not bad.
> 
> The storage change is more impacting cause of ear case which is not
> protable at all so wonder if we can do anything about it without breaking
> existing applications. Maybe we should just ensure we don't leak the
> classloader as key for now to not break anyone (we can leak if CDI doesn't
> finish to start and the application is undeployed AFAIK).
> 
> Adding the ConfigResolver as an instance in the CDI context (= a bean) is
> still an option IMHO but can wait and is more an internal refactoring than
> an API work.
> 
> wdyt? What would be the next steps? JIRA for converter method, proxy
> feature and source/filter detection in CDI?
> 
> Happy to also get some help on running it on other containers.
> 
> 
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
>  |
> LinkedIn  | JavaEE Factory
> 
> 
> 2016-11-07 9:39 GMT+01:00 Romain Manni-Bucau :
> 
>>  In the spirit of sharing and trying to move forward I started a branch on
>>  my github fork: https://github.com/rmannibucau/deltaspike/tree/
>>  fb/config-rework
>> 
>>  For now it includes 1 ("easy") and 5 (pre 2 storage but will be 
> part of
>>  the refactoring "2" normally since we'll not break this API).
>> 
>>  About 5 there is the question of the detection. By type is enough
>>  technically but wonder if we should introduce @Source and @Filter just as
>>  markers to ensure we don't also detect SPI sources and filters which 
> are
>>  likely CDI beans in a lot of apps.
>>  Feedback welcomed ^^ :).
>> 
>>  Once done, next step will be to add 3 then try to do 2. If all is good we
>>  can work on the jira tickets.
>> 
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau  |  Blog
>>   | Old Blog
>>   | Github
>>   | LinkedIn
>>   | JavaEE Factory
>>  
> 
>> 
>>  2016-11-06 21:40 GMT+01:00 Mark Struberg :
>> 
>>>  +1 for moving the Config out into an own module. It's the best we 
> can do
>>>  for now. The JSR will likely take a bit to evolve and until then we can 
> use
>>>  what we have in DeltaSpike. Just a bit cleaned up.
>>> 
>>>  LieGrue,
>>>  strub
>>> 
>>> 
>>>  PS: a single ticket is by far enough imo.
>>> 
>>> 
>>> 
>>> 
>>>  > On Sunday, 6 November 2016, 21:28, John D. Ament 
> 
>>>  wrote:
>>>  > > Some thoughts in line.
>>>  >
>>>  > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau <
>>>  rmannibu...@gmail.com>
>>>  > wrote:
>>>  >
>>>  >>  Hi guys
>>>  >>
>>>  >>  sent it some times ago - ok, a long time ago now ;) - but 
> will retry
>>>  with
>>>  >>  few more details now.
>>>  >>
>>>  >>  Goal: I'd like to rework a bit our configuration
>>>  >>
>>>  >
>>>  > How does this relate, if at all, to Mark's proposal for config 
> on
>>>  geronimo?
>>>  >
>>>  >
>>>  >>
>>>  >>  Proposals (no particular order but numbered to let it be 
> referenced):
>>>  >>  1. Add converter to @ConfigProperty (cdi lookup or fallback 
> on
>>>  >>  newInstance() probably)
>>>  >>
>>>  >
>>>  > +1
>>>  >
>>>  >
>>>  >>  2. remove the map storage we have and replace it by
>>>  >>  2.a. a thread local during the boot ConfigResolver would use
>>>  >>  2.b. a config bean for the runtime (BeanProvider or 
> CDI.current()
>>>  allow to
>>>  >>  get it easily)
>>>  >>
>>>  >
>>>  > +1000 I hate the static methods for users.
>>>  >
>>>  >
>>>  >>  3. add an interface/abstract class based configuration 
> "à la
>>>  > owner"
>>>  >>  (probably reusing @ConfigProperty)
>>>  >>
>>>  >
>>>  > I've been thinking 

Re: Config rework, take 2

[Romain Manni-Bucau]

added @Source and @Filter as markers (was breaking applications otherwise),
pushed the basic plain proxying too. Only tested with OWB for now but seems
not bad.

The storage change is more impacting cause of ear case which is not
protable at all so wonder if we can do anything about it without breaking
existing applications. Maybe we should just ensure we don't leak the
classloader as key for now to not break anyone (we can leak if CDI doesn't
finish to start and the application is undeployed AFAIK).

Adding the ConfigResolver as an instance in the CDI context (= a bean) is
still an option IMHO but can wait and is more an internal refactoring than
an API work.

wdyt? What would be the next steps? JIRA for converter method, proxy
feature and source/filter detection in CDI?

Happy to also get some help on running it on other containers.





Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2016-11-07 9:39 GMT+01:00 Romain Manni-Bucau :

> In the spirit of sharing and trying to move forward I started a branch on
> my github fork: https://github.com/rmannibucau/deltaspike/tree/
> fb/config-rework
>
> For now it includes 1 ("easy") and 5 (pre 2 storage but will be part of
> the refactoring "2" normally since we'll not break this API).
>
> About 5 there is the question of the detection. By type is enough
> technically but wonder if we should introduce @Source and @Filter just as
> markers to ensure we don't also detect SPI sources and filters which are
> likely CDI beans in a lot of apps.
> Feedback welcomed ^^ :).
>
> Once done, next step will be to add 3 then try to do 2. If all is good we
> can work on the jira tickets.
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | JavaEE Factory
> 
>
> 2016-11-06 21:40 GMT+01:00 Mark Struberg :
>
>> +1 for moving the Config out into an own module. It's the best we can do
>> for now. The JSR will likely take a bit to evolve and until then we can use
>> what we have in DeltaSpike. Just a bit cleaned up.
>>
>> LieGrue,
>> strub
>>
>>
>> PS: a single ticket is by far enough imo.
>>
>>
>>
>>
>> > On Sunday, 6 November 2016, 21:28, John D. Ament 
>> wrote:
>> > > Some thoughts in line.
>> >
>> > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >>  Hi guys
>> >>
>> >>  sent it some times ago - ok, a long time ago now ;) - but will retry
>> with
>> >>  few more details now.
>> >>
>> >>  Goal: I'd like to rework a bit our configuration
>> >>
>> >
>> > How does this relate, if at all, to Mark's proposal for config on
>> geronimo?
>> >
>> >
>> >>
>> >>  Proposals (no particular order but numbered to let it be referenced):
>> >>  1. Add converter to @ConfigProperty (cdi lookup or fallback on
>> >>  newInstance() probably)
>> >>
>> >
>> > +1
>> >
>> >
>> >>  2. remove the map storage we have and replace it by
>> >>  2.a. a thread local during the boot ConfigResolver would use
>> >>  2.b. a config bean for the runtime (BeanProvider or CDI.current()
>> allow to
>> >>  get it easily)
>> >>
>> >
>> > +1000 I hate the static methods for users.
>> >
>> >
>> >>  3. add an interface/abstract class based configuration "à la
>> > owner"
>> >>  (probably reusing @ConfigProperty)
>> >>
>> >
>> > I've been thinking about this as well.  Sounds like a good fit for
>> partial
>> > bean.
>> >
>> >
>> >>  4. extract config in its own module to let it be reused more widely
>> without
>> >>  bringing all ds core
>> >>
>> >
>> > I like the idea.  But I think the real problem is defining what is core
>> vs
>> > what is a module.  To me, core should be a lightweight component.  We've
>> > stuck some extra stuff in there that can be a pain sometimes.  May be
>> worth
>> > an entirely separate thread.
>> >
>> >
>> >>  5. support during bootstrap the detection of converters and sources
>> (not
>> >>  only propertyfile ones) and add them in the runtime config added in
>> 2.b
>> >>
>> >
>> > Well, this kind of works today.  Using a property source provider, I was
>> > able to create a archaius config source and have it discovered pretty
>> early
>> > on.
>> >
>> >
>> >>
>> >>  2. implies we don't use the config in extension constructor (which
>> > should
>> >>  be fine) and that we can cleanup the thread local after CDI startup
>> (here
>> >>  we can have few options to enforce this cleanup like using
>> >>  AfterDeploymentValidation by default + probably 

Config rework, take 2

[Romain Manni-Bucau]

Hi guys

sent it some times ago - ok, a long time ago now ;) - but will retry with
few more details now.

Goal: I'd like to rework a bit our configuration

Proposals (no particular order but numbered to let it be referenced):
1. Add converter to @ConfigProperty (cdi lookup or fallback on
newInstance() probably)
2. remove the map storage we have and replace it by
2.a. a thread local during the boot ConfigResolver would use
2.b. a config bean for the runtime (BeanProvider or CDI.current() allow to
get it easily)
3. add an interface/abstract class based configuration "à la owner"
(probably reusing @ConfigProperty)
4. extract config in its own module to let it be reused more widely without
bringing all ds core
5. support during bootstrap the detection of converters and sources (not
only propertyfile ones) and add them in the runtime config added in 2.b

2. implies we don't use the config in extension constructor (which should
be fine) and that we can cleanup the thread local after CDI startup (here
we can have few options to enforce this cleanup like using
AfterDeploymentValidation by default + probably either some container
dependent solutions or at least a ServletContextListener#contextDestroyed
for the case deployment fails)

Excepted the usability (converter option, extraction in a dedicated module)
the goal is to not do any concurrence to CDI lookup mecanism and stay 100%
aligned on it.

In term of usability the fact to be able to have a real CDI source DTO for
runtime and reuse default ones (system properties, properties in classpath,
etc..) for the extension itself (internal application configuration) is a
huge gain IMHO.

Wdyt? Any blocker?

This would likely lead to a 1.8.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory