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>
