Observer methods in abstract Extensions

[ljnelson]

Before I file a bug I would like to make sure I am not doing something stupid. (Narrator: he was probably doing something stupid.)

Consider an abstract extension, like this:

public abstract class AbstractExtension<E> implements Extension {
  void pip(@Observes ProcessInjectionPoint<?, E> e) {
    // whatever
  }
}

...and then something like:

container.addExtensions(new AbstractExtension<String>() {})

Obviously the intent here is to process injection points of type String. I think I'm seeing that the observer isn't getting called for injection points of type String. My supposition is that it is being registered for injection points of, literally, E, which seems wrong. What do we think?

[ljnelson]

Just confirming my remembered observation above. In my debugger the actual type arguments of the ProcessInjectionPoint-typed argument are a wildcard and a type variable. I would have expected the second type argument to be String (naïvely).

[ljnelson]

Update: Spoke too soon. Not sure this in fact works.

Somewhat interestingly, the workaround seems to be to define the observer method like so, unless I'm doing something else stupid:

<T extends E> void pip(ProcessInjectionPoint<?, T> e) {
  // whatever
}

[manovotn]

@ljnelson I am unable to reproduce this 🤔
Here's an SE test I tried and that works just fine for me - https://github.com/weld/core/compare/main...manovotn:core:investigate-3554-generic-extension?expand=1

I am going to need a more complete test (better still, a GH branch with a test) to see what's not working for you.

[ljnelson]

Completely fair. I will try to put one together today that is small and isolated. Obviously your test looks fine to me so who knows. I'm using Weld 6.0.4.Final if it matters.

[ljnelson]

[ljnelson]

I'm going to stop on this discussion until I can figure out what's going on. This seems to work...intermittently? That doesn't make any sense.

[ljnelson]

I'm going to delete my earlier test. Here's a better one. It seems, modulo something intermittent (some hashmap ordering, maybe?), that AbstractExtension0 subtypes work fine, but AbstractExtension1 subtypes are surprising:

package weld.discussion;

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

import jakarta.enterprise.context.Dependent;

import jakarta.enterprise.event.Observes;

import jakarta.enterprise.inject.Any;
import jakarta.enterprise.inject.Default;

import jakarta.enterprise.inject.se.SeContainer;
import jakarta.enterprise.inject.se.SeContainerInitializer;

import jakarta.enterprise.inject.spi.AfterBeanDiscovery;
import jakarta.enterprise.inject.spi.AfterDeploymentValidation;
import jakarta.enterprise.inject.spi.Extension;
import jakarta.enterprise.inject.spi.ProcessInjectionPoint;

import jakarta.inject.Inject;
import jakarta.inject.Provider;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

final class TestWeldDiscussion {

  private SeContainer container;
  
  private TestWeldDiscussion() {
    super();
  }

  @BeforeEach
  @SuppressWarnings("unchecked") // addExtensions
  final void setup() {
    this.container = SeContainerInitializer.newInstance()
      .disableDiscovery()
      .addBeanClasses(DummyBean.class)
      .addExtensions(new AbstractExtension0<String>() {},
                     new AbstractExtension1<String>() {},
                     new Extension() {
                       private final void addBean(@Observes final AfterBeanDiscovery e) {
                         e.addBean()
                           .addTransitiveTypeClosure(String.class)
                           .qualifiers(Any.Literal.INSTANCE, Default.Literal.INSTANCE)
                           .scope(Dependent.class)
                           .createWith(_ -> "Hello");
                       }
                     })
      .initialize();
  }

  @AfterEach
  final void teardown() {
    if (this.container != null) {
      this.container.close();
    }
  }

  @Test
  final void testSpike() {
    this.container.select(DummyBean.class).get();
  }

  private static class AbstractExtension0<T> implements Extension {
    private final Type arg;

    AbstractExtension0() {
      super();
      this.arg = ((ParameterizedType)this.getClass().getGenericSuperclass()).getActualTypeArguments()[0];
    }
    
    void processInjectionPoint(@Observes final ProcessInjectionPoint<?, T> e) {
      System.out.println("*** " + this.getClass().getSuperclass().getName());
      System.out.println("    pip: " + e);
      System.out.println("     ip: " + e.getInjectionPoint());
      System.out.println("   type: " + e.getInjectionPoint().getType());
      System.out.println("    arg: " + this.arg);
    }
  }

  private static class AbstractExtension1<T> implements Extension {
    private final Type arg;

    AbstractExtension1() {
      super();
      this.arg = ((ParameterizedType)this.getClass().getGenericSuperclass()).getActualTypeArguments()[0];
    }
    
    <S extends T> void processInjectionPoint(@Observes final ProcessInjectionPoint<?, S> e) {
      System.out.println("*** " + this.getClass().getSuperclass().getName());
      System.out.println("    pip: " + e);
      System.out.println("     ip: " + e.getInjectionPoint());
      System.out.println("   type: " + e.getInjectionPoint().getType());
      System.out.println("    arg: " + this.arg);
    }
  }

  private static final class DummyBean {
    @Inject
    DummyBean(final String hello) {
      super();
    }
  }
  
}

[manovotn]

Right, it seems that when you add the extra step of method having <S extends T>, Weld is no longer able to connect the dots and figure out that it should be String and instead lands on Object.
This is reproducible without issues.

Also, it isn't limited to extensions registered as instances (or as anonymous classes), all ways or adding an extension would IMO be affected.