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.

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>
>> 
>> 

Reply via email to