Le jeu. 22 nov. 2018 à 17:04, Bruno Baptista <[email protected]> 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 <[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> >> >>
