From Rick Hightower:

There should be a standard, minimalistic way to bootstrap a CDI container outside of Java EE. This is useful for unit testing extensions, and for other JSRs that need to do annotation processing, injection and interception. Instead of those other JSRs defining their own mechanism for annotation processing, injection and interception they can just use CDI.

Also Java EE has clients (for JMS, RMI, Services). The same features on the serverside (injection, interceptions, proxying) are equally useful on the client side.

There should also be some clear walls between what is included in Java SE CDI and Java EE CDI. Java SE CDI being a subset and core of Java EE CDI. This modularity should be better defined in the specification.

Just wondering, has there been any update on this?

I've spun out CDI-160 to split up the spec.

The more I think about it, the more I'm sure that we need to push this to the EE7 umbrella spec.

Booting the CDI container alone is nice, but by far not sufficient.

EJB has already an API to boot the container (javax.ejb.embeddable.EJBContainer), CDI might get one too. But still the user will end up not being able to start his whole environment!

Imagine a situation where a user likes to use openejb or JBossAS7-embedded in a SE environment. Starting the container alone would not be enough. Otoh one could argue that in those cases a user might easily use the containers native implementation specific classes directly. Wdyt?

Slipping Java SE issues, we don't have time or scope in CDI 1.1 to address them.

We're speaking through this again on the 2.0 EG.

The current proposal is to add a new interface (tentatively called CDIContainer ) which will handle the creation of the container.

The possible package is javax.enterprise.inject.spi or javax.enterprise.inject.spi.container or something else.

It's expected to have 2 or 3 methods in it

init();

init(Map<?,?> params);

shutdown();

An alternative proposal that does not prevent parallel container instances:

public abstract class ControlledCDI<T> extends CDI<T> implements AutoCloseable {

    public static ControlledCDI<Object> initialize() {

        // TODO: Use CDIProvider internally to talk to the impl

    }

    public static ControlledCDI<Object> initialize(Map<String, Object> properties) {

        // TODO: Use CDIProvider internally to talk to the impl

    }

    public abstract void close();

}

Usage:

        try (ControlledCDI<Object> cdi = ControlledCDI.initialize()) {

            Foo foo = cdi.select(Foo.class).get();

            System.out.println(foo.computeResult());

        }

Note that this is a preliminary proposal. The class name is subject to change plus we'll most likely need a builder API instead of the static methods in the end.

Class scanning and context control will be addressed in other tickets : CDI-529 and CDI-530

We have overlooked an issue regarding multiple container support.
http://cdi-development-mailing-list.1064426.n5.nabble.com/It-seems-we-missed-a-point-in-CDIProvider-enhancement-tt5711451.html.
Correction for EDR1 or enhance proposal should be done to address this point.