[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456911#comment-16456911
 ] 

ASF subversion and git services commented on DELTASPIKE-1335:
-

Commit 6e7005fe35cf0a608e84ee8e7534ba6510e9b838 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=6e7005f ]

DELTASPIKE-1335 add onChange callback and improve docs for ConfigSnapshot logic


> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same 
> request and the underlying config changes then we might up with a wild 
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
>  // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get 
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the 
> new port 8081. And this will obviously blow up because that host+port 
> combination doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: InterceptorStrategy?

[Romain Manni-Bucau]

2018-04-27 11:57 GMT+02:00 Mark Struberg :

> 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  >:
> >
> > 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  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | Book
> >  ee-8-high-performance>
> >
> > 2018-04-27 9:04 GMT+02:00 Mark Struberg :
> >
> >> In theory you are right.
> >>
> >> But adding an Interceptor Bean is WAY more work than having a
> standard
> >> @InterceptorBinding.
> >> And it also created lots of compatibility issues with older containers.
> >> Wheras @InterceptorBinding works everywhere.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 27.04.2018 um 08:51 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-04-27 8:38 GMT+02:00 Mark Struberg :
> >>>
>  No, it's not reinventing the wheel because those parts are missing in
> >> the
>  CDI spec.
> 
>  The point is to keep the same  but you can switch
> >> the
>  actual behaviour purely via config.
>  That way we don't need to change the beans.xml content for switching
> >> e.g.
>  between resource_local and UserTransaction handling for
> @Transactional.
> 
>  And this is important because otherwise users would need to re-package
>  deltaspike jars :(
> 
>  So no, there is imo no way to do the same functionality in CDI - not
> >> even
>  CDI-2.0
> 
> >>>
> >>> Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
> >>> versions).
> >>> An extension is perfectly able to do that since you can add the
> >> interceptor
> >>> programmatically when needed and select the impl at the same time, no?
> >>> I don't see the blocker we would have.
> >>>
> >>>
> 
>  LieGrue,
>  strub
> 
> 
> 
> > Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> > :
> >
> > there are 2 issues:
> >
> > 1. we reinvent the wheel and do a competitive API compared to CDI
> > 2. most of them - except maybe tx one - will never be implemented by
> >> any
> > user
> >
> > So we kind of encourage users to do it wrong.
> >
> > Always thought it was technical workarounds so now we are in 2018 I
> >> think
> > we can slowly hide it or even drop it when not relevant (all core
> > interceptors pby)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github   rmannibucau> |
> > LinkedIn  | Book
> >   ee-8-high-performance>
> >
> > 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >
> >> 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  >:
> >>
> >>> Still means it doesnt have to be in the API right?
> >>>
> >>> Le 26 avr. 2018 00:44, "Gerhard Petracek" 

Re: InterceptorStrategy?

[Mark Struberg]

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 :
> 
> 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  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 2018-04-27 9:04 GMT+02:00 Mark Struberg :
> 
>> In theory you are right.
>> 
>> But adding an Interceptor 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 >> :
>>> 
>>> 2018-04-27 8:38 GMT+02:00 Mark Struberg :
>>> 
 No, it's not reinventing the wheel because those parts are missing in
>> the
 CDI spec.
 
 The point is to keep the same  but you can switch
>> the
 actual behaviour purely via config.
 That way we don't need to change the beans.xml content for switching
>> e.g.
 between resource_local and UserTransaction handling for @Transactional.
 
 And this is important because otherwise users would need to re-package
 deltaspike jars :(
 
 So no, there is imo no way to do the same functionality in CDI - not
>> even
 CDI-2.0
 
>>> 
>>> Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
>>> versions).
>>> An extension is perfectly able to do that since you can add the
>> interceptor
>>> programmatically when needed and select the impl at the same time, no?
>>> I don't see the blocker we would have.
>>> 
>>> 
 
 LieGrue,
 strub
 
 
 
> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
> :
> 
> there are 2 issues:
> 
> 1. we reinvent the wheel and do a competitive API compared to CDI
> 2. most of them - except maybe tx one - will never be implemented by
>> any
> user
> 
> So we kind of encourage users to do it wrong.
> 
> Always thought it was technical workarounds so now we are in 2018 I
>> think
> we can slowly hide it or even drop it when not relevant (all core
> interceptors pby)
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> 
>> 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 :
>> 
>>> Still means it doesnt have to be in the API right?
>>> 
>>> Le 26 avr. 2018 00:44, "Gerhard Petracek"  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 >> :
 
> 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.
> 

Re: InterceptorStrategy?

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-27 9:04 GMT+02:00 Mark Struberg :

> In theory you are right.
>
> But adding an Interceptor 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  >:
> >
> > 2018-04-27 8:38 GMT+02:00 Mark Struberg :
> >
> >> No, it's not reinventing the wheel because those parts are missing in
> the
> >> CDI spec.
> >>
> >> The point is to keep the same  but you can switch
> the
> >> actual behaviour purely via config.
> >> That way we don't need to change the beans.xml content for switching
> e.g.
> >> between resource_local and UserTransaction handling for @Transactional.
> >>
> >> And this is important because otherwise users would need to re-package
> >> deltaspike jars :(
> >>
> >> So no, there is imo no way to do the same functionality in CDI - not
> even
> >> CDI-2.0
> >>
> >
> > Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
> > versions).
> > An extension is perfectly able to do that since you can add the
> interceptor
> > programmatically when needed and select the impl at the same time, no?
> > I don't see the blocker we would have.
> >
> >
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> there are 2 issues:
> >>>
> >>> 1. we reinvent the wheel and do a competitive API compared to CDI
> >>> 2. most of them - except maybe tx one - will never be implemented by
> any
> >>> user
> >>>
> >>> So we kind of encourage users to do it wrong.
> >>>
> >>> Always thought it was technical workarounds so now we are in 2018 I
> think
> >>> we can slowly hide it or even drop it when not relevant (all core
> >>> interceptors pby)
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github  >> rmannibucau> |
> >>> LinkedIn  | Book
> >>>  >> ee-8-high-performance>
> >>>
> >>> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >>>
>  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 :
> 
> > Still means it doesnt have to be in the API right?
> >
> > Le 26 avr. 2018 00:44, "Gerhard Petracek"  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  >:
> >>
> >>> 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
> 

Re: InterceptorStrategy?

[Mark Struberg]

In theory you are right.

But adding an Interceptor 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 :
> 
> 2018-04-27 8:38 GMT+02:00 Mark Struberg :
> 
>> No, it's not reinventing the wheel because those parts are missing in the
>> CDI spec.
>> 
>> The point is to keep the same  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 >> :
>>> 
>>> 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  |  Blog
>>>  | Old Blog
>>>  | Github > rmannibucau> |
>>> LinkedIn  | Book
>>> > ee-8-high-performance>
>>> 
>>> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
>>> 
 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 :
 
> Still means it doesnt have to be in the API right?
> 
> Le 26 avr. 2018 00:44, "Gerhard Petracek"  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 :
>> 
>>> 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"  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 <
 

Re: InterceptorStrategy?

[Romain Manni-Bucau]

2018-04-27 8:38 GMT+02:00 Mark Struberg :

> No, it's not reinventing the wheel because those parts are missing in the
> CDI spec.
>
> The point is to keep the same  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  >:
> >
> > 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  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | Book
> >  ee-8-high-performance>
> >
> > 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >
> >> 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 :
> >>
> >>> Still means it doesnt have to be in the API right?
> >>>
> >>> Le 26 avr. 2018 00:44, "Gerhard Petracek"  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 :
> 
> > 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"  a
>  écrit :
> >
> >> a concrete example:
> >> @Transactional
> >>
> >> ->
> >> @Interceptor is on TransactionalInterceptor whereas
> >>> InterceptorStrategy
> > is
> >> the marker interface for the strategies (and not the interceptor) -
> >>> in
> > this
> >> case TransactionStrategy.
> >>
> >> (to quickly get an overview of all interceptor-strategies you just
> >>> need
> > to
> >> open the hierarchy-view for InterceptorStrategy and you have
> >>> everything
> > you
> >> need with one step...)
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <
> >> rmannibu...@gmail.com
>  :
> >>
> >>> Hmm not sure i get it, annotations are hard to browse in IDE? Is
> >> it
> > what
> >> it
> >>> addresses?
> >>>
> >>> Le 24 avr. 2018 21:10, "Gerhard Petracek" 
> >> a
> >> écrit :
> >>>
>  hi romain,
> 
>  not really. 1 interceptor could have n strategies as candidates
>  (e.g.
> >> see
>  

Re: InterceptorStrategy?

[Mark Struberg]

No, it's not reinventing the wheel because those parts are missing in the CDI 
spec.

The point is to keep the same  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 :
> 
> 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  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> 
>> 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 :
>> 
>>> Still means it doesnt have to be in the API right?
>>> 
>>> Le 26 avr. 2018 00:44, "Gerhard Petracek"  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 :
 
> 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"  a
 écrit :
> 
>> a concrete example:
>> @Transactional
>> 
>> ->
>> @Interceptor is on TransactionalInterceptor whereas
>>> InterceptorStrategy
> is
>> the marker interface for the strategies (and not the interceptor) -
>>> in
> this
>> case TransactionStrategy.
>> 
>> (to quickly get an overview of all interceptor-strategies you just
>>> need
> to
>> open the hierarchy-view for InterceptorStrategy and you have
>>> everything
> you
>> need with one step...)
>> 
>> regards,
>> gerhard
>> 
>> 
>> 
>> 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <
>> rmannibu...@gmail.com
 :
>> 
>>> Hmm not sure i get it, annotations are hard to browse in IDE? Is
>> it
> what
>> it
>>> addresses?
>>> 
>>> Le 24 avr. 2018 21:10, "Gerhard Petracek" 
>> a
>> écrit :
>>> 
 hi romain,
 
 not really. 1 interceptor could have n strategies as candidates
 (e.g.
>> see
 TransactionStrategy for which we provide multiple
>> implementations
 out-of-the-box).
 that's the whole concept. the marker interfaces is just to find
>>> all
 strategies in a project easily.
 we have it since 02/2011 (back then it was  codi) and a lot of
 users
>> are
 using it (during the dev. process) and i haven't heard about
>> any
>> concern
 (from users).
 
 regards,
 gerhard
 
 
 
 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <
 rmannibu...@gmail.com
>> :