We can but wonder if it does not depend on wildfly version too but ultimagely we could detect it is wildfly and not capture the same BM. For standalone case it misses a web-inf/classes global BM so back to the BDA issue. By reflection you can always lookup the right one using CDI impl - forcing caller class directly - but not sure it is good.
Le sam. 9 mars 2024 à 13:15, Thomas Frühbeck <t.fruehb...@gmail.com> a écrit : > One desperate step further and success?!? > > added apache-deltaspike.properties: deltaspike.bean-manager.delegate_lookup > = false > Now all tests pass in partial-bean.impl for wildfly-build-managed! > (But then the Weld-only tests fail, reason to be identified :-/ > > The difference I understand is to use the BeanManager passed > to @AfterBeanDiscovery instead of CDI.current() > > Any ideas? > Useful approach? > Add a property for Wildfly to handle this? > > > Am Fr., 8. März 2024 um 20:49 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > 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 <t.fruehb...@gmail.com> 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 < > > > rmannibu...@gmail.com>: > > > > > > > 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? > > > > > > > > > > > > > > > > > >
