You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2018/04/23 09:46:00 UTC
InterceptorStrategy?
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>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
oki, let's do that.
Thanks Gerhard for the story behind that part of our code.
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:36 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
> imo we can re-visit the topic once we have cdi 1.1+ as our baseline,
> because with cdi 1.0 it's def. needed.
>
> regards,
> gerhard
>
>
>
> 2018-04-26 7:16 GMT+02:00 Romain Manni-Bucau <rm...@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 <gp...@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 <rm...@gmail.com>:
> > >
> > > > Still means it doesnt have to be in the API right?
> > > >
> > > > Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <
> rmannibucau@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" <gp...@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 <
> > > rmannibucau@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" <
> > gpetracek@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 <
> > > > > rmannibucau@gmail.com
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> > > > gpetracek@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.thomas@gmail.com
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > basically +1
> > > > > > > > > > > but its still used currently
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > > > > > rmannibucau@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>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@apache.org>.
imo we can re-visit the topic once we have cdi 1.1+ as our baseline,
because with cdi 1.0 it's def. needed.
regards,
gerhard
2018-04-26 7:16 GMT+02:00 Romain Manni-Bucau <rm...@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 <gp...@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 <rm...@gmail.com>:
> >
> > > Still means it doesnt have to be in the API right?
> > >
> > > Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rmannibucau@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" <gp...@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 <
> > rmannibucau@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" <
> gpetracek@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 <
> > > > rmannibucau@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> > > gpetracek@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.thomas@gmail.com
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > basically +1
> > > > > > > > > > but its still used currently
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > > > > rmannibucau@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>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-04-27 11:57 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> 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 <rmannibucau@gmail.com
> >:
> >
> > 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 <st...@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 <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> 2018-04-27 8:38 GMT+02:00 Mark Struberg <st...@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 <
> >> rmannibucau@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 <gp...@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 <rmannibucau@gmail.com
> >:
> >>>>>>
> >>>>>>> Still means it doesnt have to be in the API right?
> >>>>>>>
> >>>>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <
> rmannibucau@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" <gp...@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 <
> >>>>>> rmannibucau@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" <
> gpetracek@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 <
> >>>>>>>> rmannibucau@gmail.com
> >>>>>>>>>> :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> >>>>>>> gpetracek@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.thomas@gmail.com
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> basically +1
> >>>>>>>>>>>>>> but its still used currently
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> >>>>>>>>>> rmannibucau@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>
> >>
> >>
>
>
Re: InterceptorStrategy?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> 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 <st...@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 <rmannibucau@gmail.com
>>> :
>>>
>>> 2018-04-27 8:38 GMT+02:00 Mark Struberg <st...@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 <
>> rmannibucau@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 <gp...@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 <rm...@gmail.com>:
>>>>>>
>>>>>>> Still means it doesnt have to be in the API right?
>>>>>>>
>>>>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rmannibucau@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" <gp...@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 <
>>>>>> rmannibucau@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" <gp...@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 <
>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
>>>>>>> gpetracek@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.thomas@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> basically +1
>>>>>>>>>>>>>> but its still used currently
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
>>>>>>>>>> rmannibucau@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>
>>
>>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <rmannibucau@gmail.com
> >:
> >
> > 2018-04-27 8:38 GMT+02:00 Mark Struberg <st...@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 <
> rmannibucau@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 <gp...@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 <rm...@gmail.com>:
> >>>>
> >>>>> Still means it doesnt have to be in the API right?
> >>>>>
> >>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rmannibucau@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" <gp...@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 <
> >>>> rmannibucau@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" <gp...@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 <
> >>>>>> rmannibucau@gmail.com
> >>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> >>>>> gpetracek@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.thomas@gmail.com
> >>>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>>> basically +1
> >>>>>>>>>>>> but its still used currently
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> >>>>>>>> rmannibucau@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>
>
>
Re: InterceptorStrategy?
Posted by Mark Struberg <st...@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 <rm...@gmail.com>:
>
> 2018-04-27 8:38 GMT+02:00 Mark Struberg <st...@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 <rmannibucau@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 <gp...@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 <rm...@gmail.com>:
>>>>
>>>>> Still means it doesnt have to be in the API right?
>>>>>
>>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <
>>>> rmannibucau@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" <gp...@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 <
>>>>>> rmannibucau@gmail.com
>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
>>>>> gpetracek@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.thomas@gmail.com
>>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>> basically +1
>>>>>>>>>>>> but its still used currently
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
>>>>>>>> rmannibucau@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>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-04-27 8:38 GMT+02:00 Mark Struberg <st...@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 <rmannibucau@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 <gp...@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 <rm...@gmail.com>:
> >>
> >>> Still means it doesnt have to be in the API right?
> >>>
> >>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <
> >> rmannibucau@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" <gp...@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 <
> >>>> rmannibucau@gmail.com
> >>>>>> :
> >>>>>>>>
> >>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> >>> gpetracek@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.thomas@gmail.com
> >>>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>>> basically +1
> >>>>>>>>>> but its still used currently
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> >>>>>> rmannibucau@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>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: InterceptorStrategy?
Posted by Mark Struberg <st...@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
LieGrue,
strub
> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <rm...@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 <gp...@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 <rm...@gmail.com>:
>>
>>> Still means it doesnt have to be in the API right?
>>>
>>> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <
>> rmannibucau@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" <gp...@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 <
>>>> rmannibucau@gmail.com
>>>>>> :
>>>>>>>>
>>>>>>>>> Le 24 avr. 2018 19:18, "Gerhard Petracek" <
>>> gpetracek@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.thomas@gmail.com
>>>>>>>>>> :
>>>>>>>>>
>>>>>>>>>> basically +1
>>>>>>>>>> but its still used currently
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
>>>>>> rmannibucau@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>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@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 <gp...@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 <rm...@gmail.com>:
>
> > Still means it doesnt have to be in the API right?
> >
> > Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <
> rmannibucau@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" <gp...@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 <
> > > rmannibucau@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> > gpetracek@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.thomas@gmail.com
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > basically +1
> > > > > > > > > but its still used currently
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > > > rmannibucau@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>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@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 <rm...@gmail.com>:
> Still means it doesnt have to be in the API right?
>
> Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <rmannibucau@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" <gp...@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 <
> > rmannibucau@gmail.com
> > > >:
> > > > > >
> > > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <
> gpetracek@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.thomas@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > basically +1
> > > > > > > > but its still used currently
> > > > > > > >
> > > > > > > >
> > > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > > rmannibucau@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>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Still means it doesnt have to be in the API right?
Le 26 avr. 2018 00:44, "Gerhard Petracek" <gp...@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 <rm...@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" <gp...@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 <rm...@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" <gp...@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 <
> rmannibucau@gmail.com
> > >:
> > > > >
> > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > basically +1
> > > > > > > but its still used currently
> > > > > > >
> > > > > > >
> > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > rmannibucau@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>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@apache.org>.
#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 <rm...@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" <gp...@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 <rm...@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" <gp...@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 <rmannibucau@gmail.com
> >:
> > > >
> > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> > > > > >:
> > > > >
> > > > > > basically +1
> > > > > > but its still used currently
> > > > > >
> > > > > >
> > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > rmannibucau@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>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@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" <gp...@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 <rm...@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" <gp...@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 <rm...@gmail.com>:
> > >
> > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> > > > >:
> > > >
> > > > > basically +1
> > > > > but its still used currently
> > > > >
> > > > >
> > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> rmannibucau@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>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@apache.org>.
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 <rm...@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" <gp...@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 <rm...@gmail.com>:
> >
> > > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> > > >:
> > >
> > > > basically +1
> > > > but its still used currently
> > > >
> > > >
> > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rmannibucau@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>
> > > > >
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@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" <gp...@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 <rm...@gmail.com>:
>
> > Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> > >:
> >
> > > basically +1
> > > but its still used currently
> > >
> > >
> > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rm...@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>
> > > >
> > >
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@apache.org>.
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 <rm...@gmail.com>:
> Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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.thomas@gmail.com
> >:
>
> > basically +1
> > but its still used currently
> >
> >
> > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rm...@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>
> > >
> >
>
Re: InterceptorStrategy?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 24 avr. 2018 19:18, "Gerhard Petracek" <gp...@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 <an...@gmail.com>:
> basically +1
> but its still used currently
>
>
> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rm...@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>
> >
>
Re: InterceptorStrategy?
Posted by Gerhard Petracek <gp...@apache.org>.
it was always just a marker-interface to list all interceptor-strategies
easily.
regards,
gerhard
2018-04-24 13:47 GMT+02:00 Thomas Andraschko <an...@gmail.com>:
> basically +1
> but its still used currently
>
>
> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rm...@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>
> >
>
Re: InterceptorStrategy?
Posted by Thomas Andraschko <an...@gmail.com>.
basically +1
but its still used currently
2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <rm...@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>
>