Very odd.  OK.  Here's my META-INF/beans.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                           http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
       version="2.0"
       bean-discovery-mode="annotated">
</beans>

…and here is a cut down, won't-compile gist of my extension class:

public class MavenExtension implements Extension {

  public MavenExtension() {
    super();
  }

   private final void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery event) {
    if (event != null) {

      //
      // Types effectively bound by DefaultServiceLocator
      //
      
      event.addAnnotatedType(DefaultArtifactResolver.class, "maven").add(SingletonLiteral.INSTANCE);

      // and so on
  }

  private static final class Producers {

    @Produces
    @Singleton
    private static final ModelInterpolator produceModelInterpolator(final UrlNormalizer normalizer, final PathTranslator pathTranslator) {
      return new StringSearchModelInterpolator().setPathTranslator(pathTranslator).setUrlNormalizer(normalizer);
    }

  }

}

Also if it matters my main loop does nothing.  In other words, the test starts the container and closes it—which boots the extension of course, whereupon I notice that my Producers class gets picked up.  I would have expected that I would have to programmatically add my Producers class for its producer methods to be "seen", but I don't have to.  That seems odd to me.

(Frankly, what I really want is for those producer methods, all of which are static, to just be members of my extension class, but they are not seen in this case.)

Best,
Laird

On Mon, Mar 20, 2017 at 10:42 AM John Ament <john.ament@spartasystems.com> wrote:

So I just tried locally with Weld 3.0 CR2


public class BeanDiscoverer implements Extension {
    public void onBeans(@Observes ProcessBean<?> pb) {

    }

    @Singleton
    public static class Producers {

    }

    public static void main(String...args) {
        final SeContainer initialize = SeContainerInitializer.newInstance().initialize();
        final Producers producers = initialize.select(Producers.class).get();
        assert producers == null;
        initialize.close();
    }
}



And it correctly throws 


Exception in thread "main" org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type Producers with qualifiers  
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110)
at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown hook because JVM is shutting down. Using SimpleLogger
Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by shutdown hook

Even when I explicitly add the extension, same thing occurs (.addExtensions(BeanDiscoverer.class)).  Even when I explicitly add to META-INF/services/Extension it fails.


This is what my beans.xml looks like:


<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" bean-discovery-mode="annotated" version="2.0">
</beans>

Only when I change to all does it run fine...  You can see the full example at https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2conference/src/main/java/ws/ament/cdi/se/extensions/BeanDiscoverer.java so I'm curious to know if there's anything different between our setups.


John



From: Laird Nelson <ljnelson@gmail.com>
Sent: Monday, March 20, 2017 1:24 PM
To: John Ament; Martin Kouba; cdi-dev

Subject: Re: [cdi-dev] Bean discovery question
SE, and the initializer is brain-dead simple.

final SeContainerInitializer initializer = SeContainerInitializer.newInstance();
assert initializer != null;
try (final SeContainer container = initializer.initialize()) {
  assert container != null;
}

Best,
Laird

On Mon, Mar 20, 2017 at 10:21 AM John Ament <john.ament@spartasystems.com> wrote:

Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI, or is this within a container (and I'm guessing some custom integration)?  If you're using SE, what does your SEContainerInitializer lines look like?


John




From: cdi-dev-bounces@lists.jboss.org <cdi-dev-bounces@lists.jboss.org> on behalf of Laird Nelson <ljnelson@gmail.com>
Sent: Monday, March 20, 2017 11:12 AM
To: Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
 
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba <mkouba@redhat.com> wrote:
Weld version? Environment? Deployment structure?

3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
 
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.

Thank you; I'll file a bug once I have time to put together a test case.

Best,
Laird
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.