2018-04-27 11:57 GMT+02:00 Mark Struberg <[email protected]>:
> Even then we will not be able to change it. > > Many customer projects did extend our default InterceptorStrategies with > their own logic by @Specializes the DS versions. > Tbh, I also don't see any real benefit from moving to custom Beans instead > of easy to understand @InterceptorBinding. > It requires work for us to load an implem dynamically even when we'll never change the impl, it makes it hard to understand from a design perspective for end users cause it is not aligned on CDI, it is an API so as an user you expect to implement it whereas you never do it normally So overall it is more confusing for CDI users than helping and encourages to bypass CDI for part of the IoC which sounds very nasty. > > LieGrue, > strub > > > Am 27.04.2018 um 09:27 schrieb Romain Manni-Bucau <[email protected] > >: > > > > Ok so we are back on the compatibility constraint right? > > Do we have a clear view on this line? (like the list of impl not > supporting > > it?) > > If yes we can see when dropping it is possible. > > > > > > 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> > > > > 2018-04-27 9:04 GMT+02:00 Mark Struberg <[email protected]>: > > > >> In theory you are right. > >> > >> But adding an Interceptor<T> Bean is WAY more work than having a > standard > >> @InterceptorBinding. > >> And it also created lots of compatibility issues with older containers. > >> Wheras @InterceptorBinding works everywhere. > >> > >> LieGrue, > >> strub > >> > >>> Am 27.04.2018 um 08:51 schrieb Romain Manni-Bucau < > [email protected] > >>> : > >>> > >>> 2018-04-27 8:38 GMT+02:00 Mark Struberg <[email protected]>: > >>> > >>>> No, it's not reinventing the wheel because those parts are missing in > >> the > >>>> CDI spec. > >>>> > >>>> The point is to keep the same <interceptors><class> but you can switch > >> the > >>>> actual behaviour purely via config. > >>>> That way we don't need to change the beans.xml content for switching > >> e.g. > >>>> between resource_local and UserTransaction handling for > @Transactional. > >>>> > >>>> And this is important because otherwise users would need to re-package > >>>> deltaspike jars :( > >>>> > >>>> So no, there is imo no way to do the same functionality in CDI - not > >> even > >>>> CDI-2.0 > >>>> > >>> > >>> Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl > >>> versions). > >>> An extension is perfectly able to do that since you can add the > >> interceptor > >>> programmatically when needed and select the impl at the same time, no? > >>> I don't see the blocker we would have. > >>> > >>> > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>>> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau < > >> [email protected] > >>>>> : > >>>>> > >>>>> there are 2 issues: > >>>>> > >>>>> 1. we reinvent the wheel and do a competitive API compared to CDI > >>>>> 2. most of them - except maybe tx one - will never be implemented by > >> any > >>>>> user > >>>>> > >>>>> So we kind of encourage users to do it wrong. > >>>>> > >>>>> Always thought it was technical workarounds so now we are in 2018 I > >> think > >>>>> we can slowly hide it or even drop it when not relevant (all core > >>>>> interceptors pby) > >>>>> > >>>>> > >>>>> > >>>>> 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> > >>>>> > >>>>> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek <[email protected]>: > >>>>> > >>>>>> the concrete interceptor-strategies (like TransactionStrategy) are > >> part > >>>> of > >>>>>> our spi. your suggestion would mean that we would need to move them > as > >>>> well > >>>>>> (= remove them from the spi). > >>>>>> def. -1 for that because i know several users who are using them. > >>>>>> i really don't get the issue you have with a simple marker interface > >>>> (after > >>>>>> we have it for 7 years - including codi). > >>>>>> > >>>>>> btw. there are users out there who re-use InterceptorStrategy for > >> their > >>>>>> internal interceptor-strategies (of their own libs). > >>>>>> > >>>>>> regards, > >>>>>> gerhard > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau <[email protected] > >: > >>>>>> > >>>>>>> Still means it doesnt have to be in the API right? > >>>>>>> > >>>>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <[email protected]> a > >>>>>> écrit : > >>>>>>> > >>>>>>>> #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you > can't > >>>> get > >>>>>>> rid > >>>>>>>> of pre-configured interceptors (that's why we introduced the > >>>>>>>> interceptor-strategy concept initially). > >>>>>>>> #2 e.g. TransactionStrategy has benefits beyond that (a public > >> example > >>>>>> is > >>>>>>>> the usage in the ds-data-module) > >>>>>>>> > >>>>>>>> regards, > >>>>>>>> gerhard > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau < > [email protected] > >>> : > >>>>>>>> > >>>>>>>>> I get it but it means we add a layer on top of interceptor for > >>>>>>>>> pluggability. This is actually built in in CDI so not really > >> needed. > >>>>>>>>> > >>>>>>>>> Also the hierarchy point is fine but should be per type of > strategy > >>>>>> and > >>>>>>>>> therefore we dont need a generic one in the api. > >>>>>>>>> > >>>>>>>>> As a user if i use DS and an interceptor, do i need to impl this > >>>>>> public > >>>>>>>>> api? Never normally so this sounds more misleading or reinventing > >> the > >>>>>>>> wheel > >>>>>>>>> than anything else for me. > >>>>>>>>> > >>>>>>>>> That said we can move it in our impl modules to keep the feature > >> but > >>>>>>>> still > >>>>>>>>> a clean api. > >>>>>>>>> > >>>>>>>>> Le 24 avr. 2018 23:21, "Gerhard Petracek" <[email protected]> > a > >>>>>>>> écrit : > >>>>>>>>> > >>>>>>>>>> a concrete example: > >>>>>>>>>> @Transactional > >>>>>>>>>> > >>>>>>>>>> -> > >>>>>>>>>> @Interceptor is on TransactionalInterceptor whereas > >>>>>>> InterceptorStrategy > >>>>>>>>> is > >>>>>>>>>> the marker interface for the strategies (and not the > interceptor) > >> - > >>>>>>> in > >>>>>>>>> this > >>>>>>>>>> case TransactionStrategy. > >>>>>>>>>> > >>>>>>>>>> (to quickly get an overview of all interceptor-strategies you > just > >>>>>>> need > >>>>>>>>> to > >>>>>>>>>> open the hierarchy-view for InterceptorStrategy and you have > >>>>>>> everything > >>>>>>>>> you > >>>>>>>>>> need with one step...) > >>>>>>>>>> > >>>>>>>>>> regards, > >>>>>>>>>> gerhard > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau < > >>>>>> [email protected] > >>>>>>>> : > >>>>>>>>>> > >>>>>>>>>>> Hmm not sure i get it, annotations are hard to browse in IDE? > Is > >>>>>> it > >>>>>>>>> what > >>>>>>>>>> it > >>>>>>>>>>> addresses? > >>>>>>>>>>> > >>>>>>>>>>> Le 24 avr. 2018 21:10, "Gerhard Petracek" < > [email protected]> > >>>>>> a > >>>>>>>>>> écrit : > >>>>>>>>>>> > >>>>>>>>>>>> hi romain, > >>>>>>>>>>>> > >>>>>>>>>>>> not really. 1 interceptor could have n strategies as > candidates > >>>>>>>> (e.g. > >>>>>>>>>> see > >>>>>>>>>>>> TransactionStrategy for which we provide multiple > >>>>>> implementations > >>>>>>>>>>>> out-of-the-box). > >>>>>>>>>>>> that's the whole concept. the marker interfaces is just to > find > >>>>>>> all > >>>>>>>>>>>> strategies in a project easily. > >>>>>>>>>>>> we have it since 02/2011 (back then it was codi) and a lot of > >>>>>>>> users > >>>>>>>>>> are > >>>>>>>>>>>> using it (during the dev. process) and i haven't heard about > >>>>>> any > >>>>>>>>>> concern > >>>>>>>>>>>> (from users). > >>>>>>>>>>>> > >>>>>>>>>>>> regards, > >>>>>>>>>>>> gerhard > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau < > >>>>>>>> [email protected] > >>>>>>>>>> : > >>>>>>>>>>>> > >>>>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" < > >>>>>>> [email protected]> > >>>>>>>> a > >>>>>>>>>>>> écrit : > >>>>>>>>>>>>> > >>>>>>>>>>>>> it was always just a marker-interface to list all > >>>>>>>>>>> interceptor-strategies > >>>>>>>>>>>>> easily. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> But if it is just interceptors, doesnt @Interceptor fulfills > >>>>>>> that > >>>>>>>>>>>> already? > >>>>>>>>>>>>> > >>>>>>>>>>>>> My only concern is exposing it in api to user where it is > >>>>>>>> actually > >>>>>>>>> a > >>>>>>>>>>> dead > >>>>>>>>>>>>> interface. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> regards, > >>>>>>>>>>>>> gerhard > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2018-04-24 13:47 GMT+02:00 Thomas Andraschko < > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> basically +1 > >>>>>>>>>>>>>> but its still used currently > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau < > >>>>>>>>>> [email protected] > >>>>>>>>>>>> : > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Do we still need InterceptorStrategy? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If not, can we deprecate it and remove it from our > >>>>>> built-in > >>>>>>>>>>>>> interceptors? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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> > >> > >> > >
