[cdi-dev] Bean discovery question

[John Ament]

For me, that still doesn't discover.  The only thing I can think of is that the JAR that includes StringSearchModelInterpolator may have a beans.xml (does it?)  Also, what bean are you checking for, producers or ModelInterpolator ?


Also, I like your idea of explicitly allowing extensions to have producer methods.  We treat extensions as app scoped beans, so why not add that support?  Do you want to create a JIRA for that?


John



________________________________
From: Laird Nelson <ljnelson at gmail.com>
Sent: Monday, March 20, 2017 1:50 PM
To: John Ament; Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question

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 at spartasystems.com<mailto:john.ament at 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 at gmail.com<mailto:ljnelson at 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 at spartasystems.com<mailto:john.ament at 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 at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Laird Nelson <ljnelson at gmail.com<mailto:ljnelson at 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 at redhat.com<mailto:mkouba at 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.
________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/95551ef5/attachment-0001.html