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 startup which is not aligned on OWB startup for an EAR.
Hope it makes sense. 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> Le jeu. 3 nov. 2022 à 17:07, Jonathan Gallimore < jonathan.gallim...@gmail.com> a écrit : > Hey folks > > I've run into an interesting problem on the TomEE-side, running an EAR > file. This seems to end up with 2 injection resolvers for the application: > one for the web part of the application, and a parent for the EAR. > > When resolving by type at runtime, with large archives, we've seen a > slowdown from previous versions of OpenWebBeans. This appears to be caused > by the InjectionResolver.implResolveByType returning an empty set. TomEE > will then try the parent resolver (successfully), but the result (empty > set) in the child resolver is not cached, so it searches through the whole > set of beans each time. The result used to be cached, prior to this commit: > > https://github.com/apache/openwebbeans/commit/a6d22d2abf6d6d5a02a14be1367daacca450359d > > Could caching the empty result in the InjectionResolver be re-introduced, > albeit with a switch? (I'm happy for the default to be "don't cache"). > Interestingly, InjectionResolver.implResolveByName does cache the empty > result. I'm happy to create a PR. > > Many thanks > > Jon >
