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