EJB beans can declare their interfaces via @Local annotation and those can include even interfaces that aren't directly implemented by the bean.

This triggers a special path in our code for proxy creation and can lead to a situation where we design a proxy with package derived from one of the interfaces while trying to define it via MethodHandles.Lookup of the original bean class. This leads to errors.

Note that I wasn't able to reproduce this outside of container tests (found no other case so far where a valid bean could have a type it doesn't implement) and WFLY in-container tests won't show failures either as those use ClassLoader#defineClass directly. This problem only shows when you attempt to create such class via WeldDefaultProxyServices using MethodHandles#Lookup.

However, we can still make assertions on the expected proxy format in such scenario (as I did in the automated test in attached PR).

EDIT: I have also found out that this is reproducible by declaring a CDI bean and then modifying it's type set via ProcessBeanAttributes. Adding an interface (coming from a different package) that isn't directly implemented by the bean will trigger the same code path. Linked PR has a test demonstrating this as well.