Re: atomic access to config values

[Romain Manni-Bucau]

Le 4 avr. 2018 19:37, "Mark Struberg"  a écrit :

But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();


So even if we update the whole ftpConfig 'at once' you will end up with
mixed up information in this request, right?
The only viable solution is to have a @RequestScoped ConfigTransaction
spanning all those TypedResolvers of the whole @Configuration. At least I
could not find any better solution.


This doesnt work for at least two reasons:

1. You assume you have request scoped
2. You assume the tx has tx guarantee

The only way to have 2 is to lock the whole "current" config for the read
time (so a readwritelock for a simple impl) which makes this request scope
useless since you just need to swap the cache value and update it at once
with the lock.

LieGrue,strub



On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:

 Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes

this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache"

+1 to do it without any flag


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github 
|
LinkedIn  | Book


2018-04-04 18:40 GMT+02:00 Mark Struberg :

> We should also enhance the support to include @Configuration.
> e.g. if you have some class like
> @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
> public class FtpConfigation {  String host();  Integer port();  String
> username();  String encryptedPwd();}
>
> Then you will likely resolve all those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
>On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
>  wrote:
>
>  hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>

Re: atomic access to config values

[Mark Struberg]

But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();
 

So even if we update the whole ftpConfig 'at once' you will end up with mixed 
up information in this request, right?
The only viable solution is to have a @RequestScoped ConfigTransaction spanning 
all those TypedResolvers of the whole @Configuration. At least I could not find 
any better solution.
LieGrue,strub



On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau 
 wrote:  
 
 Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes

this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache"

+1 to do it without any flag


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-04 18:40 GMT+02:00 Mark Struberg :

> We should also enhance the support to include @Configuration.
> e.g. if you have some class like
> @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
> public class FtpConfigation {  String host();  Integer port();  String
> username();  String encryptedPwd();}
>
> Then you will likely resolve all those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
>    On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
>  wrote:
>
>  hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>
  

Re: atomic access to config values

[Romain Manni-Bucau]

Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes

this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache"

+1 to do it without any flag


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-04 18:40 GMT+02:00 Mark Struberg :

> We should also enhance the support to include @Configuration.
> e.g. if you have some class like
> @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
> public class FtpConfigation {  String host();  Integer port();  String
> username();  String encryptedPwd();}
>
> Then you will likely resolve all those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
> On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
>  wrote:
>
>  hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>

Re: atomic access to config values

[Mark Struberg]

We should also enhance the support to include @Configuration.
e.g. if you have some class like
@Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
public class FtpConfigation {  String host();  Integer port();  String 
username();  String encryptedPwd();}
 
Then you will likely resolve all those values in an atomic way. This means that 
the values are basically backed by a @RequestScoped ConfigTransaction holder.
Do we _always_ like to activate this feature?Or do we like to introduce another 
flag in the @Configuration annotation?
What about threads which have no request Context active?Should it automatically 
fallback to on-demand resolving?
LieGrue,strub

On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg 
 wrote:  
 
 hi folks!
please review the proposed solution for DELTASPIKE-1335
https://issues.apache.org/jira/browse/DELTASPIKE-1335

Not quite sure about startTransaction and ConfigTransation are the right terms. 
Happy to get feedback!

txs and LieGrue,strub
  

atomic access to config values

[Mark Struberg]

hi folks!
please review the proposed solution for DELTASPIKE-1335
https://issues.apache.org/jira/browse/DELTASPIKE-1335

Not quite sure about startTransaction and ConfigTransation are the right terms. 
Happy to get feedback!

txs and LieGrue,strub

[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425772#comment-16425772
 ] 

Mark Struberg commented on DELTASPIKE-1335:
---

pushed a proposed new API for solving this issue to a feature branch 
https://github.com/struberg/deltaspike/tree/DELTASPIKE-1335

The following JavaDoc describes the interesting parts:
https://github.com/struberg/deltaspike/blob/DELTASPIKE-1335/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/Config.java#L45

wdyt?


> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same 
> request and the underlying config changes then we might up with a wild 
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
>  // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get 
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the 
> new port 8081. And this will obviously blow up because that host+port 
> combination doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated DELTASPIKE-1335:
--
Summary: allow atomic access to n different TypedResolver values  (was: 
allow atomic acces too n different TypedResolver values)

> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same 
> request and the underlying config changes then we might up with a wild 
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
>  // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get 
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the 
> new port 8081. And this will obviously blow up because that host+port 
> combination doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DELTASPIKE-1335) allow atomic acces too n different TypedResolver values

[Mark Struberg (JIRA)]

Mark Struberg created DELTASPIKE-1335:
-

 Summary: allow atomic acces too n different TypedResolver values
 Key: DELTASPIKE-1335
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Configuration
Affects Versions: 1.9.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.9.0


If multiple related config values (TypedResolver) are accessed in the same 
request and the underlying config changes then we might up with a wild mixture 
of old and new values.

An example would be to access some 'myapp.host' and 'myapp.port':
The underlying values are 'oldserver' and '8080'.

Now consider the following code:
{code}
 // get the current host value
TypedResolver hostCfg config.resolve("myapp.host");

// and right inbetween the underlying values get 
// changed to 'newserver' and port 8082

// get the current port for the host
TypedResolver portCfg config.resolve("myapp.port");
{code}

In ths above code we would get the combination of 'oldserver' but with the new 
port 8081. And this will obviously blow up because that host+port combination 
doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425333#comment-16425333
 ] 

Mark Struberg commented on DELTASPIKE-1277:
---

Implemented together with [~elexx] and committed in 04cf7acd667d27ed8fa and 
73cb1ca7ab185a09.

 

> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled, 
> there is no way of bypassing the cache and forcefully reloading the value 
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces 
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this 
> method by resetting the {{reloadAfter}} field and adds a unit test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1295) Make @ConfigProperty.converter optional when there is only one possible converter for the considered injected type

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425328#comment-16425328
 ] 

Mark Struberg commented on DELTASPIKE-1295:
---

We should probably implement the same logic I added to mp-config. To be able to 
register a Converter the same way like a ConfigSource (java.util.ServiceLoader)?

> Make @ConfigProperty.converter optional when there is only one possible 
> converter for the considered injected type
> --
>
> Key: DELTASPIKE-1295
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1295
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Xavier Dury
>Priority: Minor
>
> Currently, {{@ConfigProperty}} can be used to inject members of types 
> {{String}}, {{Boolean}}, {{Class}}, {{Integer}}, {{Long}}, {{Float}} and 
> {{Double}}.
> Other types can be injected as well if a {{ConfigResolver.Converter}} 
> class is given in the annotation ({{@ConfigProperty(name = "...", converter = 
> MyTypeConverter.class)}}).
> The actual instance of the converter will be resolved through the 
> {{BeanManager}}.
> If there exists only one converter for the target type, it should be possible 
> to resolve the instance to be used with {{beanManager.resolveBean(new 
> ParameterizedTypeImpl(Converter.class, targetType))}}.
> So you would only need to specify the {{ConfigProperty.converter}} attribute:
> * if the field type does not directly match the parameter T in your 
> {{Converter}} or
> * if there are more than one eligible converter for that type.
> The logic should be changed to: is a converter specified in the annotation? 
> (!= default value)
> * yes: proceed with that converter
> *  no: is the target type one of the default supported types?
> ** yes: proceed without converter
> ** no: try to resolve the possible unique resolver for that type and use that 
> converter, throw an exception if there are multiple converters for that type
> What do you think?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (DELTASPIKE-1325) actively release ConfigSources and ConfigFilters if they implement Autocloseable

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-1325.
---
Resolution: Fixed

> actively release ConfigSources and ConfigFilters if they implement 
> Autocloseable
> 
>
> Key: DELTASPIKE-1325
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1325
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> When releasing the Config we should invoke close() on all the ConfigSources 
> and ConfigFilters if they implement java.lang.Autocloseable



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1325) actively release ConfigSources and ConfigFilters if they implement Autocloseable

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425305#comment-16425305
 ] 

ASF subversion and git services commented on DELTASPIKE-1325:
-

Commit 1e5003f92816ad6a55e57c81de9c0b2a1f9fe092 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=1e5003f ]

DELTASPIKE-1325 add documentation


> actively release ConfigSources and ConfigFilters if they implement 
> Autocloseable
> 
>
> Key: DELTASPIKE-1325
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1325
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> When releasing the Config we should invoke close() on all the ConfigSources 
> and ConfigFilters if they implement java.lang.Autocloseable



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (DELTASPIKE-1327) EnvironmentPropertyConfigSource is not scannable?

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-1327.
---
   Resolution: Fixed
 Assignee: Mark Struberg
Fix Version/s: 1.9.0

txs for the report, fixed!

> EnvironmentPropertyConfigSource is not scannable?
> -
>
> Key: DELTASPIKE-1327
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1327
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.1
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
>
> I noticed EnvironmentPropertyConfigSource overrides isScannable() and returns 
> false. Is this intentional? Just based on the code I don't see any reason why 
> EnvPropConfigSource is not scannable, while MapConfigSource is scannable 
> (EnvPropConfigSource extends MapConfigSource).
> Sidenote: I'm not sure this issue is a really "Bug" but I also couln't decide 
> on a more fitting Issue Type.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1327) EnvironmentPropertyConfigSource is not scannable?

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425272#comment-16425272
 ] 

ASF subversion and git services commented on DELTASPIKE-1327:
-

Commit 06e9a160f0aae59e95ff04a9cdd431a01127cf91 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=06e9a16 ]

DELTASPIKE-1327 EnvironmentConfigSource is scannable

txs to Alex Falb (elexx) for the bug report!


> EnvironmentPropertyConfigSource is not scannable?
> -
>
> Key: DELTASPIKE-1327
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1327
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.1
>Reporter: Alexander Falb
>Priority: Minor
>
> I noticed EnvironmentPropertyConfigSource overrides isScannable() and returns 
> false. Is this intentional? Just based on the code I don't see any reason why 
> EnvPropConfigSource is not scannable, while MapConfigSource is scannable 
> (EnvPropConfigSource extends MapConfigSource).
> Sidenote: I'm not sure this issue is a really "Bug" but I also couln't decide 
> on a more fitting Issue Type.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (DELTASPIKE-1322) clean up ConfigResolver

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-1322.
---
Resolution: Fixed

implementation details now got moved from API to impl

> clean up ConfigResolver
> ---
>
> Key: DELTASPIKE-1322
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1322
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 1.8.1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] ds for cdi 1.2+ only

[Mark Struberg]

I'd go for:
* 1.8.x: java7 + EE6This one is needed for older business applications. Yes, 
there are still servers running on Java7.


1.9.x: java8 + EE6There are also still a lot of WebSphere-8.5.x and JBoss EAP-6 
servers in production. Those got updates to Java8 but are still EE6! This is 
surely still 30% of the 'big' installations!

2.0.x: java8 + EE7This is likely the vast majority of production systems. What 
we would gain from switching to it is mainly to get rid of the 
'globalAlternatives' hack by using @Priority on all our built-in interceptors 
and Alternatives. But that otoh might also introduce a few minor backward 
compatibility issues for projects which made use of 'globalAlternative'. Apart 
from that I don't see much to improve.

Btw, I don't have CDI-2.0 on the radar. I think Apache Meecrowave and Hammock 
are the 2 only production ready EE8 servers right now. Maybe Payara up next in 
a few months and then JBoss EAP in some time. So who should use that? Apart 
from that, what would we effectively gain?
 
And yes, I do mostly care about real production. Happy to have a sandbox branch 
for playing around with CDI-2.0 features. But I'd not expect to become 
mainstream in big projects in the next half year.
LieGrue,strub
On Wednesday, 4 April 2018, 07:26:23 CEST, Gerhard Petracek 
 wrote:  
 
 the workarounds aren't that bad. it's just that we could drop more
reflection calls (similar to what we discussed for jdk8 and
java.util.Optional).

ok - i'll document details about the warnings during the bootstrapping
process (and if needed how to get rid of some of them).

regards,
gerhard



2018-04-04 6:13 GMT+02:00 Rudy De Busscher :

> I have not a clear view of the workarounds which are made and how
> 'bad'/hacky they are. But when we don't have major complaints about it (now
> or in the past) I would not invest too much time in a temporary version for
> CDI 1.2.
>
> so #3.
>
> Rudy
>
> On 3 April 2018 at 22:34, Romain Manni-Bucau 
> wrote:
>
> > All work for me and the apps i work on since a few years.
> >
> > Le 3 avr. 2018 22:17, "Thomas Andraschko" 
> a
> > écrit :
> >
> > > +1 for 3)
> > > the workarounds are really not that big...
> > >
> > > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only)
> > the
> > > next months.
> > >
> > > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek :
> > >
> > > > hi @ all,
> > > >
> > > > since we will need to maintain v1.8.x for a while and it's too early
> > for
> > > > using cdi 2.0 (for a while), we should discuss if we should have one
> > > branch
> > > > using cdi 1.2+.
> > > > it would allow to get rid of several workarounds (and the
> corresponding
> > > > warnings during the bootstrapping process).
> > > >
> > > > we had a short discussion in the irc-channel about the following
> > options:
> > > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+
> > > >
> > > > vs
> > > >
> > > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with
> cdi
> > > > v1.2+; ds v2: jdk8 with cdi 2.0+
> > > >
> > > > vs
> > > >
> > > > #3) we don't care about v1.2 as a min. requirement at all
> > > > (the workarounds are minimal anyway and users can continue to ignore
> > the
> > > > warnings during the bootstrapping process)
> > > >
> > > > or for sure
> > > > #4) [any other nice suggestion]
> > > >
> > > > -> please send your preferred approach
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > >
> >
>