On Sun, Mar 20, 2016 at 8:18 PM, Mark Struberg <struberg_at_yahoo.de> wrote:
> The _before_ instance interceptor clashes with the specification that the
> interceptor is a @Dependent scoped instance of the intercepted bean.
>
Obviously some rules would be different for such _before_ interceptor.
Injection of the @Inject @Intercepted bean, InvocationContext#getTarget and
the @Dependent scoped rule among others should all be considered.
Kind regards,
Arjan Tijms
>
> And I think you could easily do that in the Context#get() as explained.
>
> LieGrue,
> strub
>
>
>
>
>
> On Sunday, 20 March 2016, 20:02, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
> >
> >Hi,
> >
> >
> >
> >On Sun, Mar 20, 2016 at 11:47 AM, Mark Struberg <struberg_at_yahoo.de>
> wrote:
> >
> >My implementation didn't return the instance to the pool when the method
> got ended but only at the end of the request via a @PreDestroy in a
> @RequestScoped bean.
> >
> >
> >By itself indeed not such a bad idea, but I thought you meant you found a
> way to get interceptors to execute before Context#get ;)
> >
> >
> >A problem with doing the request scope thing is that it's another
> compromise. In this case bean instances will be unavailable for a little
> bit too long, especially if they're used early in the request and the
> request is a little longer running.
> >
> >
> >It looks like almost every approach compromises in some way. E.g. we did
> the Javassist approach before, but that one had the dependency as
> compromise, and the dummy instance return has the single dummy that needs
> to be maintained as compromise, etc.
> >
> >
> >One of the few ways that seems to be as straightforward as can be and
> doesn't compromise in any way I think is an interceptor that runs before
> Context#get does.
> >
> >
> >
> >I kind of piggy-packed the EJBs used in the current thread into a
> @RequestScoped bean. The EJB spec doesn't mandate anything else. The spec
> does barely mention pooling if I remember correctly. It's just that we are
> all used to it.
> >>
> >
> >
> >Indeed, pooling itself is barely mentioned and certainly not explicitly
> specified. It's sort of a theme in EJB to leave more aspects to be
> implementation specific than we're used from other specs.
> >
> >
> >That said, the spec does describe that a bean is available exclusively to
> a single caller and that instance variables *may* contain values set by a
> previous caller. Indeed, combined with the concept of destroying beans when
> certain types of exceptions happen, it does strongly imply something that
> we would normally call "pooling".
> >
> >
> >
> >So I'd say we don't need any additional feature in the interceptors spec
> to solve this problem.
> >>
> >
> >
> >I'm not entirely sure. It's an interesting approach, and I'll sure keep
> it in the back om my mind so thanks for mentioning it, but a "before
> interceptor" is likely still a bit more convenient and simultaneously less
> compromising.
> >
> >
> >Kind regards,
> >Arjan Tijms
> >
> >
> >
> >
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>On Sunday, 20 March 2016, 11:21, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
> >>
> >>
> >>>
> >>>
> >>>Hi Mark,
> >>>
> >>>
> >>>
> >>>
> >>>Patching in Jan Beernkink, who's working on an @Pooled annotation. This
> is for a CDI version of the pooling feature that's often seen with
> @Stateless beans. Here we desperately need interceptors to execute before
> Context#get.
> >>>
> >>>
> >>>Sounds great if there's already a way to have interceptors execute
> before Context#get is called. Can you give an example of this in code? We
> tried quite some things but were not able to pull it off.
> >>>
> >>>
> >>>The use case is that the Interceptor should be in charge of managing
> the pool with bean instances, since its the only thing that runs both
> before and after a method invocation. The Context#get only runs before, and
> therefor does not have an opportunity to return bean instances to the pool.
> >>>
> >>>
> >>>See the code here:
> https://github.com/omnifaces/cdi-ejb/tree/master/src/main/java/org/omnifaces/cdi/pooled
> >>>
> >>>
> >>>Kind regards,
> >>>Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>On Sun, Mar 20, 2016 at 9:42 AM, Mark Struberg <struberg_at_yahoo.de>
> wrote:
> >>>
> >>>Imo it is totally possible with the current interceptors spec.
> >>>>
> >>>>Do you mind explaining my your problems offline to not trash this
> thread with offtopic discussions?
> >>>>
> >>>>
> >>>>txs and LieGrue,
> >>>>strub
> >>>>
> >>>>
> >>>>
> >>>>On Wednesday, 24 February 2016, 14:28, arjan tijms <
> arjan.tijms_at_gmail.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>p.s.
> >>>>>
> >>>>>
> >>>>>A small feature request, but what about the ability for Interceptors
> to intercept before bean resolution has taken place? E.g. in CDI before
> Context#get is being called.
> >>>>>
> >>>>>
> >>>>>This could be done without API changes by using a negative value in
> @Priority for this.
> >>>>>
> >>>>>
> >>>>>The use case is implementing something like the EJB implicit pooling
> feature of @Stateless beans. This is very hard to do with interceptors that
> only get called after a bean instance is created.
> >>>>>
> >>>>>
> >>>>>Kind regards,
> >>>>>Arjan Tijms
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>On Wed, Feb 24, 2016 at 10:42 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
> >>>>>
> >>>>>Hi,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>On Wed, Feb 24, 2016 at 12:54 AM, Linda DeMichiel <
> linda.demichiel_at_oracle.com> wrote:
> >>>>>>
> >>>>>>My expectation is that this
> >>>>>>>would be an "errata MR" (Rev A) as I am not planning any API
> changes.
> >>>>>>
> >>>>>>
> >>>>>>Should the MR result in any need for behaviour changes, is there any
> plan or roadmap to apply these changes to GlassFish 5?
> >>>>>>
> >>>>>>
> >>>>>>Kind regards,
> >>>>>>Arjan Tijms
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>