Hi, We can force the CDI impl with maven classloader so just impl your own provider and serve it delegating to owb in tests code to behave as well but it is clearly not portable, should call getBeanManager(), current just resolves the provider, not the container IIRC
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 mar. 25 avr. 2023 à 21:17, Markus Jung <[email protected]> a écrit : > Hi all, > > jsonb CDI integration TCKs seem to rely on what I think is behaviour > undefined in the CDI spec: > - > https://github.com/jakartaee/jsonb-api/blob/3.0.0/tck/src/main/java/ee/jakarta/tck/json/bind/cdi/customizedmapping/adapters/AdaptersCustomizationCDITest.java#L57 > - > https://github.com/jakartaee/jsonb-api/blob/3.0.0/tck/src/main/java/ee/jakarta/tck/json/bind/cdi/customizedmapping/serializers/SerializersCustomizationCDITest.java#L54 > > CDI spec says: > > CDI.getBeanContainer(), as well as other methods on CDI, may be called > after the application initialization is completed until the application > shutdown starts. If methods on CDI are called at any other time, > non-portable behavior results. > > > Replacing owb with weld fixes the TCK tests I linked, but I don’t believe > that’s an acceptable solution. That’s just a dirty workaround to get TCKs > to run and I’m not even sure if we can do that license wise tbh > > wdyt on this? Do we ignore these CDI tests for now and try to get the TCKs > fixed? Or am I just missing something/misinterpreting the spec and this is > a OWB bug? > > > Thanks > > Markus
