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>
