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.

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.