I have a prototype of WB -> MC injection working now. The core of it is this class which is a modified version of http://www.seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework

public class WebBeansInjector<T> {

 private final InjectionTarget<T> it;
 private CreationalContext<T> creationalContext;

 WebBeansInjector(BeanManager manager, Class<T> clazz) {
 AnnotatedType<T> type = manager.createAnnotatedType(clazz);
 it = manager.createInjectionTarget(type);
 creationalContext = manager.createCreationalContext(null);
 }

 Set<InjectionPoint> getInjectionPoints()
 {
 return it.getInjectionPoints();
 }

 T instantiate()
 {
 T t = it.produce(creationalContext);
 return t;
 }

 void inject(Object instance)
 {
 it.inject((T)instance, creationalContext);
 }

 void postConstruct(Object instance) {
 it.postConstruct((T)instance);
 }

 void preDestroy(T instance) {
 it.preDestroy(instance);
 creationalContext.release();
 }
}

class McBeanUsingWebBeans{
 @Current SomeWebBean someWebBean;

 @Current AnotherWebBean anotherWebBean;

 McUsingWebBeans(@Current AnotherWebBean anotherWebBean){
 this.anotherWebBean = anotherWebBean;
 }
}

 public boolean resolve(Controller controller)
 {
 try
 {
 context.getManager().validate(injectionPoint);
 setIDependOn(injectionPoint);
// addDependsOnMe(controller, context);
 setResolved(true);
 }
 catch(ValidationException e)
 {
 setResolved(false);
 }

 return isResolved();
 }

I have committed the initial prototype for the web beans integration. It can be found here https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/webbeans-int.

MC beans that should interact with web beans are wrapped in a WebBeansKernelControllerContext as mentioned before. It contains additional controller context actions to instantiate/inject an MC bean with web beans. It also contains an additional controller context action to store mc beans that should be available for injection to web beans in a registry. It contains a web beans AfterBeanDiscovery implementation that is used to add the mc beans to the web beans bean manager. The mc beans added to web beans are done in a custom web beans Bean implementation that takes the existing instance from mc, ignoring the calls to create it. When running in AS there will be a loads and loads of MC beans, which might unintentionally conflict, so we need to find a good way to narrow down which MC beans are available for injection into web beans. Currently, I am only registering MC beans that have web beans annotations on them (ignoring producer methods), but am open for suggestions on how to improve this.

I am unsure how this fits together in the real world though. The WebBeansKernelControllerContext needs access to a bean manager to be able to call createCreationalContext(), createInjectionTarget() and createAnnotatedType().

For cases when we want to inject MC->WB, the MC beans need to be deployed and 'registered' before the web beans are deployed, and the actual bean manager to be used is created during the deployment process. I have hacked around this for now, by creating a 'bootstrap' bean manager in my tests that is available before web beans are deployed. Luckily, none of the BeanManager methods needed for this process (createAnnotatedType()) do anything with the internal state of the bean manager, so they work.

For WB->MC injection, we need access to the correct bean manager that should be used to inject the MC beans, so createCreationalContext() and createInjectionTarget() can be called. I think for this to work we need access to the 'real' BeanManager. So, how do we determine which BeanManager should be used?

The registry mentioned currently stores the context names and web beans Bean implementations, but we probably need to take scoped controllers into account there. So how do we determine which controller should be used for a particular bean manager?

For MC->WB injection, the MC beans need to be deployed first so that they are registered with the bean manager. For WB->MC injection, the WB beans need to be deployed first since the MC WebBeansKernelControllerContext gets initialised with the bean manager on creation. I think the MC beans needing to be deployed first is pretty definite, but it would be good if the bean manager to be used for WB->MC could be determined somehow at a later stage.

I am currently ignoring the fact that there are other Bean implementations than SimpleBean, and also not handling WebBeansKernelControllerContexts for bean factories

Reply from Pete Muir:

"kabir.khan@jboss.com" wrote:
I have committed the initial prototype for the web beans integration. It can be found here https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/webbeans-int.

MC beans that should interact with web beans are wrapped in a WebBeansKernelControllerContext as mentioned before. It contains additional controller context actions to instantiate/inject an MC bean with web beans. It also contains an additional controller context action to store mc beans that should be available for injection to web beans in a registry. It contains a web beans AfterBeanDiscovery implementation that is used to add the mc beans to the web beans bean manager. The mc beans added to web beans are done in a custom web beans Bean implementation that takes the existing instance from mc, ignoring the calls to create it. When running in AS there will be a loads and loads of MC beans, which might unintentionally conflict, so we need to find a good way to narrow down which MC beans are available for injection into web beans. Currently, I am only registering MC beans that have web beans annotations on them (ignoring producer methods), but am open for suggestions on how to improve this.

I am unsure how this fits together in the real world though. The WebBeansKernelControllerContext needs access to a bean manager to be able to call createCreationalContext(), createInjectionTarget() and createAnnotatedType().

For cases when we want to inject MC->WB, the MC beans need to be deployed and 'registered' before the web beans are deployed, and the actual bean manager to be used is created during the deployment process. I have hacked around this for now, by creating a 'bootstrap' bean manager in my tests that is available before web beans are deployed. Luckily, none of the BeanManager methods needed for this process (createAnnotatedType()) do anything with the internal state of the bean manager, so they work.

"kabir.khan@jboss.com" wrote:

For WB->MC injection, we need access to the correct bean manager that should be used to inject the MC beans, so createCreationalContext() and createInjectionTarget() can be called. I think for this to work we need access to the 'real' BeanManager. So, how do we determine which BeanManager should be used?

As I have mentioned on team calls I think there will be some problems with weld-int once we support JSR-330 annotations natively in MC. Here is a chat between me and Ales describing the problem and a half-baked idea for a way around it once I get the chance to look at it again:

[03/02/2010 16:12:03] Kabir Khan: I've had an idea about the Weld/MC/JSR330 stuff

[03/02/2010 16:12:14] Kabir Khan: Not sure if it is viable or not

[03/02/2010 16:12:38] Kabir Khan: but I think the problem is that at the moment ALL JSR 330 injection is deferred to weld

[03/02/2010 16:13:02] Kabir Khan: once we support JSR 330 in MC, the problem I foresee is distiguishing between the two

[03/02/2010 16:13:07] Ales Justin: jsr33 has no injection

[03/02/2010 16:13:12] Ales Justin: it's just a bunch of annotations

[03/02/2010 16:13:29] Kabir Khan: It defines @Inject (or whatever it is called)

[03/02/2010 16:13:37] Ales Justin: yes

[03/02/2010 16:13:45] Kabir Khan: and basically weld-int handles that

[03/02/2010 16:13:53] Kabir Khan: if we want to natively support this in MC

[03/02/2010 16:13:58] Kabir Khan: then we have a problem

[03/02/2010 16:14:07] Ales Justin: even with qualifiers?

[03/02/2010 16:14:18] Kabir Khan: yes, weld takes the whole AnnotatedType

[03/02/2010 16:14:31] Kabir Khan: which is basically all the methods etc.

[03/02/2010 16:14:40] Kabir Khan: and looks for the ones with @Inject in weld

[03/02/2010 16:15:01] Kabir Khan: so there is no clear way to distinguish between the ones from weld and the ones from MC

[03/02/2010 16:15:25] Kabir Khan: However AnnotatedType allows the use of decorators, which I already use to add qualifiers from MDR

[03/02/2010 16:15:31] Kabir Khan: e.g.

[03/02/2010 16:15:34] Kabir Khan: if I have

[03/02/2010 16:15:39] Kabir Khan: class Blah{

[03/02/2010 16:16:03] Kabir Khan:    @Inject Other other;

   @Inject THing thing;

}

[03/02/2010 16:16:22] Kabir Khan: and Other is not a weld bean weld will throw up

[03/02/2010 16:16:30] Kabir Khan: What I am thinking of is

[03/02/2010 16:16:44] Kabir Khan: it might be possible to fo

[03/02/2010 16:16:45] Kabir Khan: do

[03/02/2010 16:17:19] Kabir Khan: @Inject Other other;

@Inject @Weld Thing thing;

[03/02/2010 16:17:34] Kabir Khan: in an MC bean to specify that thing should come from weld

[03/02/2010 16:17:48] Kabir Khan: and other comes from MC annotations directly

[03/02/2010 16:18:02] Kabir Khan: When passing the annotated type in to weld for injection

[03/02/2010 16:18:20] Kabir Khan: the decorated annotated type could leave out things that don't have @Weld

[03/02/2010 16:18:38] Kabir Khan: Just a vague thought I had right now

I have updated the jsr330 branch and will merge to trunk once I have a added a few more tests. The kernel now supports the JSR 330 usage of @javax.inject.Inject, e.g.:

public class SomeBean
{
   @Inject @SomeQualifier Thing t;

   @Inject 
   public SomeBean(@SomeQualifier Thing t){}

   @Inject
   public void setThingA(@SomeQualifier Thing t){}

   @Inject @SomeQualifier
   public void setThingB(Thing t){}

   @Inject
   public void installMethod(@SomeQualifier Thing t, @OtherQualifier Thing t2){}

}

If we have the following MC bean

public class MyBean{

   @Inject Thing t;

   @Weld @Inject Other o;

}

t will be injected from the MC using contextual injection, while o will be injected from Weld. This is done by maintaining a registry of annotations that should be ignored by the @Inject annotation plugins, so if the member also has one of those annotations (e.g. @Weld) we don't create the standard MC injection value metadata for it.

When creating the weld injection we create a weld AnnotatedType for the bean, for which there is a decorator that looks at the MDR metadata for the bean. I modified the getAnnotations(), isAnnotationPresent() and getAnnotation() methods to strip out the @Inject unless @Weld is also present, so that weld does not try to inject into those members.

To make an MC bean injectable into Weld it needs the @WeldEnabled annotation, e.g.:

If we have the following MC bean

@WeldEnabled
public class McBeanForWeld{
}