Deployment dependencies via WebMetaData and ServiceMetaData

[brian.stansberry]

Discussion related to http://jira.jboss.com/jira/browse/JBAS-4763

AIUI, if you add a element to a jboss-web.xml, that results in a call to WebMetaData.addDependency(). In AbstractWarDeployer.deployWebModule() those dependencies get converted into ServiceDependencyMetaData objects in ServiceMetaData.dependencies. From there, my assumption is that data somehow gets converted into DeploymentUnit dependencies.

The last bit doesn't seem to happen, which I believe is the cause of JBAS-4763. A search for usage of ServiceMetaData.getDependencies() doesn't show anything but a unit test.[/url]

[brian.stansberry]

I think I have this fixed, or at least it's doing something meaningful.

The problem was a missing List.add() call in AbstractWarDeployer.deployWebModule().

With that fixed if you deploy a war with a bogus depends element, you'll get the CONTEXTS MISSING DEPENDENCIES logging from HDScanner. But you also get a logging saying it "deployed xyz.war". The WebModule from the war will still appear in the jmx-console, and there's no attribute or anything to show that it's not running. And if you invoke the create or start operation on the console mbean, you get no complaint.

I have a suspicion that what really should happen and isn't is that any dependencies from the JBossWebMetaData need to get pushed into the DeploymentUnit.

[starksm64]

The war deployment unit essentially is the ServiceDeployment that contains the war mbeans. That is where the dependencies should show up, and any failures should be failing that deployment. Just need to look into how the deployment is being cleaned up on failure.

[brian.stansberry]

I walked through this in a debugger yesterday and didn't see any logic to "fail" from a missing dependency. ServiceController's install/create/start methods tell the KernelController to bring the context to CONFIGUGRED/CREATE/START and just log a debug if something prevents that.

Basically it looks the deployment remains registered, waiting for the missing dependency to be resolved, which could happen at any future time. Only indication of a problem is if someone like HDScanner calls MainDeployer.checkComplete() and logs the DeploymentException.

Leaving the deployment in place waiting for the dependency to be resolved seems fine actually, as long as we make sure any code we write that initiates deployments also calls checkComplete() and does something useful with the output. [1] IIRC, that's how AS 4 works as well.

The thing that definitely did seem bad was the jmx-console mbean for the WebModule was pretty useless. No attribute to tell you what ControllerState it was in, just the lifecycle ops.

[1] A bunch of our unit tests in o.j.test.deployers try to deploy things and don't call checkComplete(). I suspect this may leave them vulnerable to thinking a deployment has completed when it really hasn't. For JBAS-4763 I created a test based on the others and got bit by that.

[starksm64]

There are a couple of related checkComplete issues, and yes, a missing dependency at the end of a deployment won't be enough to fail it. The current deployment process() call needs to perform a checkComplete type of validation to detect unresolved dependencies. I have upped the priority of JBAS-4292 to critical for beta4.

http://jira.jboss.com/jira/browse/JBAS-4292
http://jira.jboss.com/jira/browse/JBAS-4684

[alesj]

[1] A bunch of our unit tests in o.j.test.deployers try to deploy things and don't call checkComplete(). I suspect this may leave them vulnerable to thinking a deployment has completed when it really hasn't. For JBAS-4763 I created a test based on the others and got bit by that.

I guess those tests were ported from 4.x.
Thus out of date, as discussed a couple of times. :-(
We need to update them/create new, to fit 5.x and the new deployers.
I'm planning on doing this for CR1.

[alesj]

There are a couple of related checkComplete issues, and yes, a missing dependency at the end of a deployment won't be enough to fail it. The current deployment process() call needs to perform a checkComplete type of validation to detect unresolved dependencies.

I guess the same behavior is needed for mbeans / ServiceDeployer:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=123665