You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2018/11/22 10:57:29 UTC
safeguard: do we align it on other Microprofile impls?
There are several discussions about safeguard so i'd like we try to get a
dedicated thread about it and see how we move forward this lib.
Personally I'd like to align it on the way other impls are done which
concretely means:
1. drop failsafe
2. probably drop the API module which mainly adds builders and definition
models to make it part of the implementation and stick to the spec in terms
of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable
programmatically if needed too, this is not one or the other) to let the
nested components be injected and overridable one by one instead of having
to override them all
5. try to respect CDI model and not use reflections in interceptors (drop
AnnotationUtil), this is likely the hardest since the spec does not enables
it directly but we did with quite some success in other specs
I did a quick check and once 2 is done the effort for 1 is very doable and
3/4 are quite trivial
Wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Done, we can now continue the hacking on master
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 5 déc. 2018 à 09:23, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Will wait a few hours and plan to merge it in beginning of the afternoon
> on master if nobody voices against
>
> Thanks for your feedback guys
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 5 déc. 2018 à 09:06, Jean-Baptiste Onofré <jb...@nanthrax.net> a
> écrit :
>
>> +1 to create our own stuff.
>>
>> I would be more than happy to help on this one !
>>
>> Regards
>> JB
>>
>> On 03/12/2018 15:24, Romain Manni-Bucau wrote:
>> > Hello guys,
>> >
>> >
>> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
>> > is now ready and I'd like to move it forward and merge it as our new
>> > master. Here is the proposal
>> >
>> > 1. branch current master in 1.0.x - just to keep the code somewhere
>> > 2. merge the branch on master (1.1-SNAPSHOT would likely become
>> > 1.1.0-SNAPSHOT at the same time)
>> >
>> > I'll be "off" next week so if we can make it this week it is awesome
>> > otherwise I can probably do it the week of the 17th and do a Xmas
>> > release with other implementations.
>> >
>> > Let me know if there is any issue about that plan and it needs some
>> > adjustments.
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github
>> > <https://github.com/rmannibucau> | LinkedIn
>> > <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <rmannibucau@gmail.com
>> > <ma...@gmail.com>> a écrit :
>> >
>> > There are several discussions about safeguard so i'd like we try to
>> > get a dedicated thread about it and see how we move forward this
>> lib.
>> >
>> > Personally I'd like to align it on the way other impls are done
>> > which concretely means:
>> >
>> > 1. drop failsafe
>> > 2. probably drop the API module which mainly adds builders and
>> > definition models to make it part of the implementation and stick to
>> > the spec in terms of exposed API
>> > 3. merge tck module in the implementation module
>> > 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
>> > usable programmatically if needed too, this is not one or the other)
>> > to let the nested components be injected and overridable one by one
>> > instead of having to override them all
>> > 5. try to respect CDI model and not use reflections in interceptors
>> > (drop AnnotationUtil), this is likely the hardest since the spec
>> > does not enables it directly but we did with quite some success in
>> > other specs
>> >
>> > I did a quick check and once 2 is done the effort for 1 is very
>> > doable and 3/4 are quite trivial
>> >
>> > Wdyt?
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github
>> > <https://github.com/rmannibucau> | LinkedIn
>> > <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Will wait a few hours and plan to merge it in beginning of the afternoon on
master if nobody voices against
Thanks for your feedback guys
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 5 déc. 2018 à 09:06, Jean-Baptiste Onofré <jb...@nanthrax.net> a
écrit :
> +1 to create our own stuff.
>
> I would be more than happy to help on this one !
>
> Regards
> JB
>
> On 03/12/2018 15:24, Romain Manni-Bucau wrote:
> > Hello guys,
> >
> >
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
> > is now ready and I'd like to move it forward and merge it as our new
> > master. Here is the proposal
> >
> > 1. branch current master in 1.0.x - just to keep the code somewhere
> > 2. merge the branch on master (1.1-SNAPSHOT would likely become
> > 1.1.0-SNAPSHOT at the same time)
> >
> > I'll be "off" next week so if we can make it this week it is awesome
> > otherwise I can probably do it the week of the 17th and do a Xmas
> > release with other implementations.
> >
> > Let me know if there is any issue about that plan and it needs some
> > adjustments.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <rmannibucau@gmail.com
> > <ma...@gmail.com>> a écrit :
> >
> > There are several discussions about safeguard so i'd like we try to
> > get a dedicated thread about it and see how we move forward this lib.
> >
> > Personally I'd like to align it on the way other impls are done
> > which concretely means:
> >
> > 1. drop failsafe
> > 2. probably drop the API module which mainly adds builders and
> > definition models to make it part of the implementation and stick to
> > the spec in terms of exposed API
> > 3. merge tck module in the implementation module
> > 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
> > usable programmatically if needed too, this is not one or the other)
> > to let the nested components be injected and overridable one by one
> > instead of having to override them all
> > 5. try to respect CDI model and not use reflections in interceptors
> > (drop AnnotationUtil), this is likely the hardest since the spec
> > does not enables it directly but we did with quite some success in
> > other specs
> >
> > I did a quick check and once 2 is done the effort for 1 is very
> > doable and 3/4 are quite trivial
> >
> > Wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 to create our own stuff.
I would be more than happy to help on this one !
Regards
JB
On 03/12/2018 15:24, Romain Manni-Bucau wrote:
> Hello guys,
>
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
> is now ready and I'd like to move it forward and merge it as our new
> master. Here is the proposal
>
> 1. branch current master in 1.0.x - just to keep the code somewhere
> 2. merge the branch on master (1.1-SNAPSHOT would likely become
> 1.1.0-SNAPSHOT at the same time)
>
> I'll be "off" next week so if we can make it this week it is awesome
> otherwise I can probably do it the week of the 17th and do a Xmas
> release with other implementations.
>
> Let me know if there is any issue about that plan and it needs some
> adjustments.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <rmannibucau@gmail.com
> <ma...@gmail.com>> a écrit :
>
> There are several discussions about safeguard so i'd like we try to
> get a dedicated thread about it and see how we move forward this lib.
>
> Personally I'd like to align it on the way other impls are done
> which concretely means:
>
> 1. drop failsafe
> 2. probably drop the API module which mainly adds builders and
> definition models to make it part of the implementation and stick to
> the spec in terms of exposed API
> 3. merge tck module in the implementation module
> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
> usable programmatically if needed too, this is not one or the other)
> to let the nested components be injected and overridable one by one
> instead of having to override them all
> 5. try to respect CDI model and not use reflections in interceptors
> (drop AnnotationUtil), this is likely the hardest since the spec
> does not enables it directly but we did with quite some success in
> other specs
>
> I did a quick check and once 2 is done the effort for 1 is very
> doable and 3/4 are quite trivial
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: safeguard: do we align it on other Microprofile impls?
Posted by Mark Struberg <st...@yahoo.de>.
+1 to brew our own. Yes Bruno is right that the jodah.failsafe is obviously more battle tested. But by relying on an almost dormant external lib we loose the ability to quickly fix bugs and add improvements ourselves.
And tbh safeguard is really not that a complex matter.
LieGrue,
Strub
Sent with autocorrect...
> On 03.12.2018, at 15:24, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hello guys,
>
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring is now ready and I'd like to move it forward and merge it as our new master. Here is the proposal
>
> 1. branch current master in 1.0.x - just to keep the code somewhere
> 2. merge the branch on master (1.1-SNAPSHOT would likely become 1.1.0-SNAPSHOT at the same time)
>
> I'll be "off" next week so if we can make it this week it is awesome otherwise I can probably do it the week of the 17th and do a Xmas release with other implementations.
>
> Let me know if there is any issue about that plan and it needs some adjustments.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
>> Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>> There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.
>>
>> Personally I'd like to align it on the way other impls are done which concretely means:
>>
>> 1. drop failsafe
>> 2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
>> 3. merge tck module in the implementation module
>> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
>> 5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs
>>
>> I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial
>>
>> Wdyt?
>>
>> Romain Manni-Bucau
>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
Re: safeguard: do we align it on other Microprofile impls?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hello guys,
https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
is now ready and I'd like to move it forward and merge it as our new
master. Here is the proposal
1. branch current master in 1.0.x - just to keep the code somewhere
2. merge the branch on master (1.1-SNAPSHOT would likely become
1.1.0-SNAPSHOT at the same time)
I'll be "off" next week so if we can make it this week it is awesome
otherwise I can probably do it the week of the 17th and do a Xmas release
with other implementations.
Let me know if there is any issue about that plan and it needs some
adjustments.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> There are several discussions about safeguard so i'd like we try to get a
> dedicated thread about it and see how we move forward this lib.
>
> Personally I'd like to align it on the way other impls are done which
> concretely means:
>
> 1. drop failsafe
> 2. probably drop the API module which mainly adds builders and definition
> models to make it part of the implementation and stick to the spec in terms
> of exposed API
> 3. merge tck module in the implementation module
> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
> usable programmatically if needed too, this is not one or the other) to let
> the nested components be injected and overridable one by one instead of
> having to override them all
> 5. try to respect CDI model and not use reflections in interceptors (drop
> AnnotationUtil), this is likely the hardest since the spec does not
> enables it directly but we did with quite some success in other specs
>
> I did a quick check and once 2 is done the effort for 1 is very doable and
> 3/4 are quite trivial
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Bruno Baptista <br...@gmail.com>.
Hi All,
Can someone please release Safeguard 1.0.1?
There are changes we need released before committing the new work.
Cheers
Bruno Baptista
https://twitter.com/brunobat_
On 22/11/18 16:40, Bruno Baptista wrote:
> Sorry Romain,
>
> I got lost here, without a concrete example I might not be able to
> understand what you mean.
>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 22/11/18 16:26, Romain Manni-Bucau wrote:
>> skip failsafe in the webapp to make us work (and break a user) or the
>> opposite in some TCCL cases.
Re: safeguard: do we align it on other Microprofile impls?
Posted by Bruno Baptista <br...@gmail.com>.
Sorry Romain,
I got lost here, without a concrete example I might not be able to
understand what you mean.
Cheers
Bruno Baptista
https://twitter.com/brunobat_
On 22/11/18 16:26, Romain Manni-Bucau wrote:
> skip failsafe in the webapp to make us work (and break a user) or the
> opposite in some TCCL cases.
Re: safeguard: do we align it on other Microprofile impls?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 22 nov. 2018 à 17:04, Bruno Baptista <br...@gmail.com> a écrit :
> Hi Romain,
>
> 1. Because Failsafe is a battle tested library. For me it's more important
> to have a hardened implementation than avoid issues with container
> isolation. Do you have an example or a test for one of those issues?
>
Ok so let's dig this one, failsafe is not that active (since may), has a
committer base close of the same magnitude than us so at the end doing it
ourself or not is the same game IMHO - you would note the other MP impl
don't use failsafe neither.
In terms of example you can take the old ones of tomee where we will either
skip failsafe in the webapp to make us work (and break a user) or the
opposite in some TCCL cases.
> 2. The TCK are external validation tests. I prefer the current separation.
> I see your point of fast test feedback but, again, the tests in the
> implementation should be safegard tests to make the lib as good as possible
> and then, see if it passes the TCK.
>
Will not fight much this one but at the end other specs respect that so in
the spirit to make it uniform I still see it as having value. That said
other points have way more values for end users so not something we need to
discuss if we don't agree yet.
> I can live with an installed lib that doesn't pass the TCK. We only need
> to make sure it's working before we release.
>
> Cheers and thanks for your interest.
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 22/11/18 13:07, Romain Manni-Bucau wrote:
>
>
>
>
> Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <br...@gmail.com> a
> écrit :
>
>> Hi Romain,
>>
>> 1. Against in the near future. Too much effort, risk and a long time to
>> harden the code without obvious gains.
>>
>
> Why? :)
>
> Also note that in tomee this is key to avoid issues since tomee does not
> want of container/app isolation (for good reasons)
> Finally half of the required impl is not in the lib so it is like
> importing commons-lang to do placeholder handling in an app, likely
> overkilled.
>
>
>> 2. +1
>>
>> 3. why?
>>
>
> To not install/deploy a failling module, most of the impl tests are the
> tck so this is a bad practise to have it tested after it is installed - and
> can lead to broken deployments.
>
>
>> 4. +0
>>
>> 5. There will be additional changes around the interceptor.
>>
>> On a general note, I'm more concerned in implementing the MP-FT features
>> than re-write the whole thing and in the end be in the same place were we
>> started.
>>
>> Cheers.
>> Bruno Baptista
>> https://twitter.com/brunobat_
>>
>>
>>
>> On 22/11/18 10:57, Romain Manni-Bucau wrote:
>>
>> There are several discussions about safeguard so i'd like we try to get a
>> dedicated thread about it and see how we move forward this lib.
>>
>> Personally I'd like to align it on the way other impls are done which
>> concretely means:
>>
>> 1. drop failsafe
>> 2. probably drop the API module which mainly adds builders and definition
>> models to make it part of the implementation and stick to the spec in terms
>> of exposed API
>> 3. merge tck module in the implementation module
>> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
>> usable programmatically if needed too, this is not one or the other) to let
>> the nested components be injected and overridable one by one instead of
>> having to override them all
>> 5. try to respect CDI model and not use reflections in interceptors (drop
>> AnnotationUtil), this is likely the hardest since the spec does not
>> enables it directly but we did with quite some success in other specs
>>
>> I did a quick check and once 2 is done the effort for 1 is very doable
>> and 3/4 are quite trivial
>>
>> Wdyt?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Bruno Baptista <br...@gmail.com>.
Hi Romain,
1. Because Failsafe is a battle tested library. For me it's more
important to have a hardened implementation than avoid issues with
container isolation. Do you have an example or a test for one of those
issues?
2. The TCK are external validation tests. I prefer the current
separation. I see your point of fast test feedback but, again, the tests
in the implementation should be safegard tests to make the lib as good
as possible and then, see if it passes the TCK.
I can live with an installed lib that doesn't pass the TCK. We only need
to make sure it's working before we release.
Cheers and thanks for your interest.
Bruno Baptista
https://twitter.com/brunobat_
On 22/11/18 13:07, Romain Manni-Bucau wrote:
>
>
>
> Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <brunobat@gmail.com
> <ma...@gmail.com>> a écrit :
>
> Hi Romain,
>
> 1. Against in the near future. Too much effort, risk and a long
> time to harden the code without obvious gains.
>
>
> Why? :)
>
> Also note that in tomee this is key to avoid issues since tomee does
> not want of container/app isolation (for good reasons)
> Finally half of the required impl is not in the lib so it is like
> importing commons-lang to do placeholder handling in an app, likely
> overkilled.
>
> 2. +1
>
> 3. why?
>
>
> To not install/deploy a failling module, most of the impl tests are
> the tck so this is a bad practise to have it tested after it is
> installed - and can lead to broken deployments.
>
> 4. +0
>
> 5. There will be additional changes around the interceptor.
>
> On a general note, I'm more concerned in implementing the MP-FT
> features than re-write the whole thing and in the end be in the
> same place were we started.
>
> Cheers.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
>
> On 22/11/18 10:57, Romain Manni-Bucau wrote:
>> There are several discussions about safeguard so i'd like we try
>> to get a dedicated thread about it and see how we move forward
>> this lib.
>>
>> Personally I'd like to align it on the way other impls are done
>> which concretely means:
>>
>> 1. drop failsafe
>> 2. probably drop the API module which mainly adds builders and
>> definition models to make it part of the implementation and stick
>> to the spec in terms of exposed API
>> 3. merge tck module in the implementation module
>> 4. probably make FailsafeExecutionManager a cdi bean (we can keep
>> it usable programmatically if needed too, this is not one or the
>> other) to let the nested components be injected and overridable
>> one by one instead of having to override them all
>> 5. try to respect CDI model and not use reflections in
>> interceptors (drop AnnotationUtil), this is likely the hardest
>> since the spec does not enables it directly but we did with quite
>> some success in other specs
>>
>> I did a quick check and once 2 is done the effort for 1 is very
>> doable and 3/4 are quite trivial
>>
>> Wdyt?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <br...@gmail.com> a écrit :
> Hi Romain,
>
> 1. Against in the near future. Too much effort, risk and a long time to
> harden the code without obvious gains.
>
Why? :)
Also note that in tomee this is key to avoid issues since tomee does not
want of container/app isolation (for good reasons)
Finally half of the required impl is not in the lib so it is like importing
commons-lang to do placeholder handling in an app, likely overkilled.
> 2. +1
>
> 3. why?
>
To not install/deploy a failling module, most of the impl tests are the tck
so this is a bad practise to have it tested after it is installed - and can
lead to broken deployments.
> 4. +0
>
> 5. There will be additional changes around the interceptor.
>
> On a general note, I'm more concerned in implementing the MP-FT features
> than re-write the whole thing and in the end be in the same place were we
> started.
>
> Cheers.
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
>
> On 22/11/18 10:57, Romain Manni-Bucau wrote:
>
> There are several discussions about safeguard so i'd like we try to get a
> dedicated thread about it and see how we move forward this lib.
>
> Personally I'd like to align it on the way other impls are done which
> concretely means:
>
> 1. drop failsafe
> 2. probably drop the API module which mainly adds builders and definition
> models to make it part of the implementation and stick to the spec in terms
> of exposed API
> 3. merge tck module in the implementation module
> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
> usable programmatically if needed too, this is not one or the other) to let
> the nested components be injected and overridable one by one instead of
> having to override them all
> 5. try to respect CDI model and not use reflections in interceptors (drop
> AnnotationUtil), this is likely the hardest since the spec does not
> enables it directly but we did with quite some success in other specs
>
> I did a quick check and once 2 is done the effort for 1 is very doable and
> 3/4 are quite trivial
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
Re: safeguard: do we align it on other Microprofile impls?
Posted by Bruno Baptista <br...@gmail.com>.
Hi Romain,
1. Against in the near future. Too much effort, risk and a long time to
harden the code without obvious gains.
2. +1
3. why?
4. +0
5. There will be additional changes around the interceptor.
On a general note, I'm more concerned in implementing the MP-FT features
than re-write the whole thing and in the end be in the same place were
we started.
Cheers.
Bruno Baptista
https://twitter.com/brunobat_
On 22/11/18 10:57, Romain Manni-Bucau wrote:
> There are several discussions about safeguard so i'd like we try to
> get a dedicated thread about it and see how we move forward this lib.
>
> Personally I'd like to align it on the way other impls are done which
> concretely means:
>
> 1. drop failsafe
> 2. probably drop the API module which mainly adds builders and
> definition models to make it part of the implementation and stick to
> the spec in terms of exposed API
> 3. merge tck module in the implementation module
> 4. probably make FailsafeExecutionManager a cdi bean (we can keep it
> usable programmatically if needed too, this is not one or the other)
> to let the nested components be injected and overridable one by one
> instead of having to override them all
> 5. try to respect CDI model and not use reflections in interceptors
> (drop AnnotationUtil), this is likely the hardest since the spec does
> not enables it directly but we did with quite some success in other specs
>
> I did a quick check and once 2 is done the effort for 1 is very doable
> and 3/4 are quite trivial
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>