@Paul: not really, none define any behavior (note that the class loader tree implementation is a vendor choice, several certified EE servers do handle singleton per tree or per loader of the tree and it is compliant). Only @inject tests are https://github.com/eclipse-ee4j/injection-tck/blob/2ef97bfc0439f28730d4d1793f1ef9ff21309450/src/main/java/org/atinject/tck/auto/Convertible.java#L176 which are mainly smoke tests to let vendors handle instances as they want (proxy or not, eager vs lazy, scope/context definition etc). All that still leads to the fact that the Maven IoC is not obvious on our doc, no?
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. 5 févr. 2021 à 13:55, Paul Hammant <p...@hammant.org.invalid> a écrit : > > > > JSR 330 has a TCK that defines a lot. A system that purports to > facilitate > > injection into contained components (plugins or lesser) doesn’t have to > > implement all facets of that TCK but could do so out of the box by just > > using (say) guice or dagger in a class loader tree implementation. >
