I think the main reason we wanted to split it was due to not confusing the use cases of booting CDI and accessing the CDI container.

On 19 Dec 2014, at 11:03, Antoine Sabot-Durand <antoine@sabot-durand.net> wrote:

Hi guys,

As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE.

I just made a small test adding this class to weld-se :

public class WeldSEProvider extends WeldProvider {

    private static boolean firstTime = true;

    @Override
    public CDI<Object> getCDI() {
        if (firstTime) {
            new Weld().initialize();
            firstTime = false;
        }

        return super.getCDI();
    }

}


and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider

org.jboss.weld.environment.se.WeldSEProvider

Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes :

public class Main {
    
    public static void main(String[] args) throws Exception {
        CDI cdi = CDI.current();
        BeanManager bm = cdi.getBeanManager();
        
    }
    
}


Similar CDIProvider can be written for OWB as well.

I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it’s not as complete as the one we plan to push in CDI 2.0

Antoine