Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-2763

Proxy generation for bean with unassignable types in their type sets


    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 6.0.0.Alpha1, 5.1.3.Final
    • 3.1.9.Final, 4.0.3.Final, 5.1.2.Final
    • Proxies
    • None

      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.

            manovotn Matěj Novotný
            manovotn Matěj Novotný
            0 Vote for this issue
            1 Start watching this issue