3

As far as I understand "pre-CDI" EJB and resources injection solutions (@EJB, @Resource and others, to be clear) use the JNDI service to locate objects "known" to the container by virtue of being JNDI registered, and then inject them where requested.

CDI, instead, relies on bean-discovery-mode parameter (ALL or ANNOTATED) to discover beans that need to be managed. But how is this process actually performed? A runtime scan of... what? Is JNDI not involved at all?

I have the feeling I'm getting something wrong about the whole mechanism...

Luigi Cortese
  • 10,841
  • 6
  • 37
  • 48
  • 1
    JNDI is only used to grab `BeanManager`. Then it just scans classpath for annotated classes. This is chewed out in among others http://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime – BalusC Feb 25 '16 at 16:26

1 Answers1

2

The bean discovery process is described in detail in the CDI specification. Basically, the CDI container scans bean deployment archives for classes with certain annotations.

JNDI is not involved at all. Unlike EJBs, CDI beans cannot be looked up via JNDI in general.

Only the BeanManager itself can be looked up under the name of java:comp/BeanManager, but this is almost never required, unless you need to access managed beans from unmanaged code.

Harald Wellmann
  • 12,615
  • 4
  • 41
  • 63
  • 2
    Moreover, since CDI 1.1 there's [`CDI`](http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/CDI.html) utility class making it unnecessary to grab `BeanManager` in unmanaged code. – BalusC Mar 06 '16 at 18:27