They were JDK classes. My extension (https://github.com/soulwing/pinject) does property injection into fields like String, primitives, and other types that have a simple textual representations that can be put in a properties file. Bean.getBeanClass was return the target type of the injection point. Now it returns the class of the POJO that holds the derived property value; Bean.getTypes returns the targeted type.

Looking at https://github.com/wildfly/wildfly/blob/a8db4da1415a1b497d73c7e3c9717906ca88896c/weld/src/main/java/org/jboss/as/weld/deployment/WeldDeployment.java

it appears that integration is creating a new BDA for each individual bean class that isn’t found on a module class loader. In getBeanDeploymentArchive if it doesn't find the class on one of the module class loaders, it returns null. In createAndRegisterAdditionalBeanDeploymentArchive it falls through to line 208 where (based on comments at line 205) it looks like the intent was to ignore classes from the bootstrap class loader. If the class has no class loader, it doesn't put the BDA in the map, but it does add it to the list of BDAs – i.e. we get a new BDA with the same ID for each class on the bootstrap class loader, and Weld doesn't like that.