Details

      Description

      Weld and other CDI impls allow an embedded mode.

      See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            pmuir Pete Muir added a comment -

            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.

            Show
            pmuir Pete Muir added a comment - 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.
            Hide
            meetoblivion John Ament added a comment -

            Just wondering, has there been any update on this?

            Show
            meetoblivion John Ament added a comment - Just wondering, has there been any update on this?
            Hide
            pmuir Pete Muir added a comment -

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

            Show
            pmuir Pete Muir added a comment - I've spun out CDI-160 to split up the spec.
            Hide
            struberg Mark Struberg added a comment -

            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?

            Show
            struberg Mark Struberg added a comment - 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?
            Hide
            pmuir Pete Muir added a comment -

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

            Show
            pmuir Pete Muir added a comment - Slipping Java SE issues, we don't have time or scope in CDI 1.1 to address them.
            Hide
            meetoblivion John Ament added a comment -

            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();
            

            Show
            meetoblivion John Ament added a comment - 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();
            Hide
            jharting Jozef Hartinger added a comment -

            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.

            Show
            jharting Jozef Hartinger added a comment - 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.
            Hide
            antoinesabot-durand Antoine Sabot-Durand added a comment -

            Class scanning and context control will be addressed in other tickets

            Show
            antoinesabot-durand Antoine Sabot-Durand added a comment - Class scanning and context control will be addressed in other tickets

              People

              • Assignee:
                meetoblivion John Ament
                Reporter:
                pmuir Pete Muir
              • Votes:
                5 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development