You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2017/11/27 13:32:40 UTC
propertyfileconfig and lifecycle
Hi guys,
I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
Issue is AfterDeploymentValidation order of extensions is not
deterministic and therefore we can end up in cases where our
extensions are not usable in between them cause of that. it is
typically the case for the config extension which is used by all other
ones.
To solve it - keeping the deterministic behavior we have - we can:
1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
2. have a single AfterDeploymentValidation observer in all our
codebase and be able to sort extensions here (@Priority or a custom
@Order). Note we can apply it to [Before|After]BeanDiscovery too.
3. surely others
Goal is to ensure the mainstream programming model we have works in
most cases and there is no arbitrary reason to not have it working.
wdyt? Personally I'm tempted to say 2. is not a bad compromise and
would bring a lot of value by itself even if not 100% aligned on CDI
programming model.
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
Re: propertyfileconfig and lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
works for me, thks Mark
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
2017-11-27 15:51 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:
> We can move it from AfterDeploymentValidation to AfterBeanDiscovery.
> My argument was about why we _not_ do it immediately in ProcessAnnotatedType.
>
> Will go ahead.
>
> LieGrue,
> strub
>
>> Am 27.11.2017 um 14:32 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>
>> Hi guys,
>>
>> I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
>>
>> Issue is AfterDeploymentValidation order of extensions is not
>> deterministic and therefore we can end up in cases where our
>> extensions are not usable in between them cause of that. it is
>> typically the case for the config extension which is used by all other
>> ones.
>>
>> To solve it - keeping the deterministic behavior we have - we can:
>>
>> 1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
>> 2. have a single AfterDeploymentValidation observer in all our
>> codebase and be able to sort extensions here (@Priority or a custom
>> @Order). Note we can apply it to [Before|After]BeanDiscovery too.
>> 3. surely others
>>
>> Goal is to ensure the mainstream programming model we have works in
>> most cases and there is no arbitrary reason to not have it working.
>>
>> wdyt? Personally I'm tempted to say 2. is not a bad compromise and
>> would bring a lot of value by itself even if not 100% aligned on CDI
>> programming model.
>>
>> Romain Manni-Bucau
>> @rmannibucau | Blog | Old Blog | Github | LinkedIn
>
Re: propertyfileconfig and lifecycle
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
We can move it from AfterDeploymentValidation to AfterBeanDiscovery.
My argument was about why we _not_ do it immediately in ProcessAnnotatedType.
Will go ahead.
LieGrue,
strub
> Am 27.11.2017 um 14:32 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi guys,
>
> I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
>
> Issue is AfterDeploymentValidation order of extensions is not
> deterministic and therefore we can end up in cases where our
> extensions are not usable in between them cause of that. it is
> typically the case for the config extension which is used by all other
> ones.
>
> To solve it - keeping the deterministic behavior we have - we can:
>
> 1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
> 2. have a single AfterDeploymentValidation observer in all our
> codebase and be able to sort extensions here (@Priority or a custom
> @Order). Note we can apply it to [Before|After]BeanDiscovery too.
> 3. surely others
>
> Goal is to ensure the mainstream programming model we have works in
> most cases and there is no arbitrary reason to not have it working.
>
> wdyt? Personally I'm tempted to say 2. is not a bad compromise and
> would bring a lot of value by itself even if not 100% aligned on CDI
> programming model.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn