Hmm, not sure I got it all but weld uses BDA isolation - no link to classloaders, linked to physical jars/folders even in the same classloader. The web-inf/classes can also see more than the web-inf/lib/x.jar due to that - but it is a spec abuse AFAIK. This is a blurry line in the CDI spec where vendors never agreed upon.
I guess we can just detect it is weld and fallback on multiple captured bm (jndi, provider one, CDI.current()) but it stays very fragile. 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 ven. 8 mars 2024 à 19:34, Thomas Frühbeck <[email protected]> a écrit : > Follow-Up: when designing Weld-only test I had missed a detail :-/ > Now following Weld-only test works perfectly fine! > > I desingned a bm#interceptorLookup on an injected BM in the arquillian > test: works fine! > > The interceptor resolution inside DS by injected(!) > DeltaSpikeProxyInterceptorLookup fails! > > So it seems that finally the reason may be the deployment isolation in > Wildfly?! > > According docs web-archives should have flat CL, so I see no reason for > isolation, I could not find any related configuration :-/ > > I designed a simple 2-module web-app to simulate "reverse-visibility" > issue: no problem detected!! > > Maybe the problem is related to the time, when BeanManagerProviderExtension > is fired - due to concurrent CL? > I will try to simulate, but anyway: the problem seems to be substantial. > > How to proceed? > Suggestions much appreciated! > > Simple Weld-only test: > weld = new Weld().disableDiscovery() > .addExtension(new BeanManagerProvider()) > .addExtension(new PartialBeanBindingExtension()) > .addInterceptor(CustomInterceptorImpl.class) > .addPackages(CustomInterceptor.class, PartialBean.class, > DeltaSpikeProxyInvocationHandler.class) > .addBeanClass(PartialBean.class); > container = weld.initialize(); > beanManager = container.getBeanManager(); > deltaSpikeProxyInterceptorLookup = > > BeanProvider.getContextualReference(DeltaSpikeProxyInterceptorLookup.class); > > PartialBean partialBean = > BeanProvider.getContextualReference(PartialBean.class); > List<Interceptor<?>> interceptorListBm = > beanManager.resolveInterceptors(InterceptionType.AROUND_INVOKE, new > AnnotationLiteral<CustomInterceptor>() {}); > Assert.assertFalse(interceptorListBm.isEmpty()); > > List<Interceptor<?>> interceptorList = > deltaSpikeProxyInterceptorLookup.lookup(partialBean, > PartialBean.class.getMethod("getResult")); > Assert.assertFalse(interceptorList.isEmpty()); > > > > Am Di., 5. März 2024 um 21:46 Uhr schrieb Romain Manni-Bucau < > [email protected]>: > > > Not sure what does weld in standalone mode but there JNDI is undefined. > > That said it is still a change in behavior so a regression. > > Anyone spotted that in the spec or is it a new BDA interpretation of > weld? > > > > Fact that the behavior is broken in wildfly and broken in standalone > > compared to old version is fishy, means we should use the BM only in > > extension somehow which is just not compatible with most CDI code so I'm > > quite hesitant to modify DS where Weld is likely the culprit, wdyt? > > > > > > >
