Le mar. 8 nov. 2022 à 22:18, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :
> On Tue, Nov 8, 2022 at 6:56 PM Romain Manni-Bucau
> wrote:
>
> > Indeed we can always add a pluggable (by config) cache but how many cases
> > does it cover?
> >
>
> To be fair, OWB is pretty friendly in t
On Tue, Nov 8, 2022 at 6:56 PM Romain Manni-Bucau
wrote:
> Indeed we can always add a pluggable (by config) cache but how many cases
> does it cover?
>
To be fair, OWB is pretty friendly in terms of being pluggable. If the 2
hash maps in InjectionResolver had protected access rather than private
Indeed we can always add a pluggable (by config) cache but how many cases
does it cover?
>From what I saw it always hides another issue - in the ActionServlet the
other issue is the usage of CDI.current() for ex which is itself a hotspot
and not defined in the sample case (ear).
So is it worth? Not
Le mar. 8 nov. 2022 à 17:26, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :
> Thanks for the reply. Its possibly a tangent, but if the intention is to
> not cache misses, I'm curious as to why misses are cached when resolving by
> name:
>
>
> https://github.com/apache/openwebbeans/bl
> On Nov 8, 2022, at 7:50 AM, Romain Manni-Bucau wrote:
>
> Hi Jon,
>
> It is intended to not cache the missed hits since they shouldn't occur at
> runtime and would open the door to OOME issues.
> I looked at your sample, there is indeed a bug in ActionServlet#process
> which should do that res
Thanks for the reply. Its possibly a tangent, but if the intention is to
not cache misses, I'm curious as to why misses are cached when resolving by
name:
https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/container/InjectionResolver.java#L395
Actio
Hi Jon,
It is intended to not cache the missed hits since they shouldn't occur at
runtime and would open the door to OOME issues.
I looked at your sample, there is indeed a bug in ActionServlet#process
which should do that resolution in init().
>From my XP frameworks using that kind of resolution
Thanks for the reply, Romain!
There's a couple of points on this one. Firstly, it's not startup behaviour
that's an issue in this specific case, it's actually resolution at runtime.
In effect, because the child InjectionResolver cannot resolve the bean, and
never caches that fact, it tries to work
Hi Jon,
The fix Thomas did is accurate and needed so think we should be fine like
that but I also agree the "pre-fix" implementation of TomEE never caught up
this change.
I guess the fix is to ensure the wrappers we have in TomEE also have this
kind of behavior but handling the cache for TomEE sta
