InitialContext.lookup() does not find Jetty Resources

[lrasku]

Jetty version(s)
12.1.6

Jetty Environment
Confirmed in ee11 & ee10, likely affects others too

HTTP version
Shouldn't matter

Java version/vendor (use: java -version)
openjdk version "21.0.10" 2026-01-20 LTS
OpenJDK Runtime Environment (Red_Hat-21.0.10.0.7-1) (build 21.0.10+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-21.0.10.0.7-1) (build 21.0.10+7-LTS, mixed mode, sharing)

OS type/version
AlmaLinux 9.7 (Moss Jungle Cat)

Description
To make BeanManager available via JNDI on Jetty, Weld 5.1.6 instructs to add a reference to it as a org.eclipse.jetty.plus.jndi.Resource. The official example uses jetty-env.xml markup, which should translate directly into the following Java code:

new Resource(webAppContext, "BeanManager", new Reference(
    "jakarta.enterprise.inject.spi.BeanManager",
    "org.jboss.weld.resources.ManagerObjectFactory",
    null
));

And indeed, if I then try to inject BeanManager in a webapp like

@Resource(name="BeanManager")
private BeanManager beanManager;

it works. But some libraries want to look it up at runtime:

BeanManager beanManager = (BeanManager)new InitialContext().lookup("java:comp/env/BeanManager");

And this fails; BeanManager is not found. But if I define BeanManager as an EnvEntry:

new EnvEntry(webAppContext, "BeanManager", new Reference(
    "jakarta.enterprise.inject.spi.BeanManager",
    "org.jboss.weld.resources.ManagerObjectFactory",
    null
), true);

The previous line starts working.

Looking into it, the problem seems to be that org.eclipse.jetty.eeX.plus.webapp.EnvConfiguration.configure only binds EnvEntries into the webapp's context, not Resources. (@Resource injection works, because org.eclipse.jetty.eeX.annotations.ResourceAnnotationHandler.handleField does not do regular JNDI lookups internally, and instead interrogates the source scopes directly.)

I haven't done any spec lawyering on this, so I'm not 100% sure if Jetty is actually in the wrong here, but a resource-ref being available for @Resource injection but not InitialContext.lookup seems unintuitive to say the least?

How to reproduce?
Attached is a minimal Maven project to reproduce the problem. When compiled with mvn package and ran with java -jar target/jetty-jndi-problem-0.0.0.jar, it serves a page at http://localhost:9000/context/servlet that gives you "HTTP ERROR 500 java.lang.RuntimeException: javax.naming.NameNotFoundException; remaining name 'BeanManager'". When you replace Resource with EnvEntry in the source code, the error goes away, and the same page prints a string representation of the BeanManager.

jetty-jndi-problem.zip

[joakime]

The mentioned link to weld documentation is bad, and reports a 404.

For CDI the recommended approach is to use the jetty-ee10-cdi (works with weld 5.1.x) or jetty-ee11-cdi (works with weld 6.0.x) artifacts.

Those, in turn, use a combination of Jetty ServletContainerInitializer, and a Weld ServletContainerInitializer, and the existence of jakarta.enterprise.inject.spi.CDIProvider (ServiceLoader) resources from the classloader.

Not sure why the weld references are attempting to do any of that via JNDI.

We have an example at https://github.com/jetty/jetty-examples/tree/12.1.x/embedded/ee10-jersey-weld

Of special note, you should probably exclude some transitive dependencies in weld-servlet-core that are known to cause problems.

    <dependency>
      <groupId>org.jboss.weld.servlet</groupId>
      <artifactId>weld-servlet-core</artifactId>
      <version>${weld.version}</version>
      <exclusions>
        <exclusion>
          <groupId>io.undertow</groupId>
          <artifactId>*</artifactId>
        </exclusion>
        <exclusion>
          <groupId>javax.enterprise</groupId>
          <artifactId>cdi-api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

[lrasku]

Are you sure about the link? It works for me. Screencap of the relevant part of the documentation:

Weld does not require any of this JNDI bootstrapping for CDI itself, but the Jakarta CDI spec says that BeanManager should be made available over JNDI, and e.g. Eclipse Soteria relies on this behavior.

That said, this Resource/EnvEntry confusion doesn't really have anything to do with Weld, since I can reproduce the problem with just a plain String resource too. Example project.