I'm looking at the as weld-int project how to integrate the work I have done on MC's weld-int.

Here's an outline of what I believe I have to do

== 1 - Initialize Weld =====This is done by BootstrapBean.initialize(). The BeanMetaData for BootstrapBean is created by WeldBootstrapDeployer, and deployed by BeanMetaDataDeployer.

== 2 - Deploy the MC beans using WeldKernelControllerContext so that we can have Weld->MC injection, and also be pushed to weld for MC->Weld injection =====a) I need the BeanManager. BootstrapBean is initialised, so I can call BB.getWeldManager(). I do however need access to the bean manager to use, which I can get from the (Flat)Deployment attachment. I do see some issues down the line if a deployment has several bean managers, but want to get something up and running before digging into that.b) How do I make sure that WeldKernelControllerContexts are deployed instead of KernelControllerContexts? Replace BeanMetaDataDeployer with something else?

== 3 - Deploy Weld beans =====This is done by BootstrapBean.boot() which is called as part of BootstrapBean's start phase. I need to make sure this happens after 2), which looks like it is the case in BootDeployerTestCase, due to some mysterious dependency on EjbContainer#1 (line 79)

b) How do I make sure that WeldKernelControllerContexts are deployed instead of KernelControllerContexts? Replace BeanMetaDataDeployer with something else?

Just noting down an idea before I finish for the weekend

Maybe I need similar deployers to KernelDeploymentDeployer/BeanMetaDataDeployer that come before those. A WeldKernelDeploymentDeployer could kick in if the MC beans are part of a Weld deployment, it could remove the KernelDeployment attachment, then wrap it as a WeldKernelDeployment attachment, with a DeploymentVisitor to create WeldBeanMetaDatas which would be picked up by a WeldBeanMetaDataDeployer which would deploy WeldKernelControllerContexts. That would cover the MC beans that are part of a Weld deployment, the question is what about the MC beans that are not part of a weld deployment? Only the WeldKernelControllerContexts are currently registered for pushing to Weld for MC->Weld injection.

a) I need the BeanManager. BootstrapBean is initialised, so I can call BB.getWeldManager(). I do however need access to the bean manager to use, which I can get from the (Flat)Deployment attachment. I do see some issues down the line if a deployment has several bean managers, but want to get something up and running before digging into that.

This is the name under which BootstrapBean is registered in MC: * String bootstrapName = DeployersUtils.getBootstrapBeanName(unit);

This is done by BootstrapBean.boot() which is called as part of BootstrapBean's start phase. I need to make sure this happens after 2), which looks like it is the case in BootDeployerTestCase, due to some mysterious dependency on EjbContainer#1 (line 79)

a) I need the BeanManager. BootstrapBean is initialised, so I can call BB.getWeldManager(). I do however need access to the bean manager to use, which I can get from the (Flat)Deployment attachment. I do see some issues down the line if a deployment has several bean managers, but want to get something up and running before digging into that.

This is the name under which BootstrapBean is registered in MC:* String bootstrapName = DeployersUtils.getBootstrapBeanName(unit);

I have a chicken and egg situation :-) When creating WeldKernelControllerContexts in the BeanMetaDataDeployer plugin, I need a reference to the BeanManager:

However, since everything is deployed by the BeanMetaDataDeployer there is not really a way to make sure that we are deploying the BeanManager. Unless you know of a nicer way I think I'll end up doing something along the lines of:

*) The DESCRIBE state is probably too early, so I will probably need a WELD_EXTRA_DESCRIBE state or something like that to initialise the WeldInjector for WeldKernelControllerContexts, which I am currently doing as part of the DESCRIBE state.

I would simply install a new temp bean,which gets BeanManager injected at a proper state.

I've had some success with this. The main stumbling block at the moment is that each of my tests run in isolation is fine, but if I try to run them all I get an error on next test setup:

java.lang.IllegalStateException: Incompletely deployed:
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean" is missing the following dependencies:
Dependency "vfs://top-level.ear/_JBossDeployment" (should be in state "Installed", but is actually not found)
Dependency "vfs://top-level.ear/_WeldBootstrapBean" (should be in state "Create", but is actually not found)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.validate(MicrocontainerTestDelegate.java:262)
at org.jboss.test.kernel.junit.MicrocontainerTest.afterSetUp(MicrocontainerTest.java:117)
at org.jboss.test.kernel.junit.MicrocontainerTest.setUp(MicrocontainerTest.java:91)
at org.jboss.test.deployers.BootstrapDeployersTest.setUp(BootstrapDeployersTest.java:350)
at org.jboss.test.deployers.test.AbstractWeldTest.setUp(AbstractWeldTest.java:59)

'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' is the "intermediate" bean that installs SimpleBean once BootstrapBean is installed. How to make sure it gets uninstalled along with the deployment? I tried adding it as an attachment in the WeldKernelControllerContextCreator (used by BeanMetaDataDeployer) which creates this bean but it is not uninstalled.

To summarize, I have a bean called SimpleBean. BMDDeployer + WeldKernelControllerContextCreator install 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' instead, and this in turn installs SimpleBean in its start() method. On uninstall BMDDeployer.undeploy() gets called with SimpleBean, but not with 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean'.

I will see if I can make 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' uninstall itself, but it feels a bit strange to do that from its start() method.

context is the context of the bean. The call to uninstall completes successfully, unconfiguring the target and setting it to null. However, when StartStopLifecycleAction completes and ends up back in incrementState() the context is picked up and moved through the remainder of the states.

It looks a bit hackish, but that's the cost of tying WeldKCC with BootstrapBean.And if I'm not yet too sleepy, this should properly cleanup.

Actually, there is another cleanup issue to take care of. ;-)e.g. WeldKCCC adds IB, but BootstrapBean is never installed (for whatever reason)This would leave IB hanging in Controller + you would get error for Controller::uninstall("real-weld-bean-name")

We should track this mapping as well* removing it once WeldKCC is installed and IB removed* actually removing IB from Controller instead of WeldKCC if the mapping is still there(this would mean that the BB was never installed)

Without that nothing really knows that it should look for the IB, which is registered in MC under a different name from the bean we actually want to install, and try to uninstall that. WKCCC could contain the registry and handle this.

Alternatively, I might need an alternative KernelControllerContext implementation that installs the IB under the original name. Once that is created, that could install another bean (IB2) whose job it is to uninstall IB and install the real bean under the original name. However, as you say that could lead to people injecting IB instead of the real bean.