CDI scanning is controlled by the bean-discovery-mode attribute in beans.xml files — the default value for this attribute is annotated. In the default mode, CDI scans for beans decorated by bean-defining annotations such as @ApplicationScoped, @RequestScoped, etc.

With the help of CDI, Helidon looks for JAX-RS Application subclasses in your Helidon application. If none are found, a synthetic application will be created by gathering all resources and providers found during the discovery phase. Note that if your Application subclass has no bean-defining annotations, and bean discovery is set to the default annotated value, it will be ignored.

The discovery phase is carried out as follows (in no particular order):

1. Collect all beans that extend Application
2. Collect all beans annotated with @Path
3. Collect all beans annotated with @Provider

If no Application subclasses are found, create a synthetic Application subclass that includes all beans gathered in steps (2) and (3) and set the application path to be "/" —this is the path normally defined using the @ApplicationPath annotation. If one or more Application subclasses are found, call the getClasses and getSingletons methods in each subclass using the collections in steps (2) and (3) only as defaults, i.e. if these methods both return empty sets.

JAX-RS provides access to the Application subclass instance via injection using @Context. This form of access is still supported in Helidon but is insufficient if two or more subclasses are present. Given that support for two or more Application subclasses is a Helidon extension, a new mechanism is provided via the ServerRequest 's context object as shown next.

import io.helidon.webserver.ServerRequest;

@Path("myresource")
public class MyResource {

    @GET
    public void get(@Context ServerRequest serverRequest) {
        Application app = serverRequest.context().get(Application.class).get();
        // ...
    }
}

This approach effectively moves the scope of Application subclass instances to request scope in order to access the correct subclass for the resource method being executed.

Jersey does not currently provide support for multiple Application subclasses. As a result, it creates a single internal injection manager for your entire application, but this is insufficient when multiple Application subclasses are present. Helidon creates a separate injection manager for each Application subclass, and a single parent injection manager for your application. Each Application subclass injection manager delegates to the parent injection manager.

Due to an implementation strategy in Jersey, ParamConverterProvider 's must be registered in the parent manager for proper registration and initialization. Thus, providers of this type will be shared and accessible by all Application subclasses, even if your code tries to limit their access. This is likely to change in future versions of Jersey/Helidon and does not typically impact how your application runs.