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 <[email protected]
<mailto:[email protected]>> 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>
