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 <strub...@yahoo.de.invalid>: > 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 <rmannibu...@gmail.com > >: > > > > 2018-04-27 8:38 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > > > >> 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 < > rmannibu...@gmail.com > >>> : > >>> > >>> 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 <gpetra...@apache.org>: > >>> > >>>> 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 <rmannibu...@gmail.com>: > >>>> > >>>>> Still means it doesnt have to be in the API right? > >>>>> > >>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gpetra...@apache.org> 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 <rmannibu...@gmail.com > >: > >>>>>> > >>>>>>> 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" <gpetra...@apache.org> 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 < > >>>> rmannibu...@gmail.com > >>>>>> : > >>>>>>>> > >>>>>>>>> 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" <gpetra...@apache.org> > >>>> 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 < > >>>>>> rmannibu...@gmail.com > >>>>>>>> : > >>>>>>>>>> > >>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" < > >>>>> gpetra...@apache.org> > >>>>>> 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 < > >>>>>>>>>> andraschko.tho...@gmail.com > >>>>>>>>>>>> : > >>>>>>>>>>> > >>>>>>>>>>>> basically +1 > >>>>>>>>>>>> but its still used currently > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau < > >>>>>>>> rmannibu...@gmail.com > >>>>>>>>>> : > >>>>>>>>>>>> > >>>>>>>>>>>>> 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> > >
