Circular dependency error msg problem

[starksm64]

I'm seeing two problems with the IncompleteDeploymentException msg that results when the problem is due to circular references.

1. The processing of AbstractDependencyInfo.resolveDependencies aborts as soon as there is an unresolved dependency. This leaves spurious unresolved dependencies in the missing dependency list.

2. When the IncompleteDeployments.calculateContextsError tries to calculate the underlying context in error by removing contexts with missing dependencies, it ends up claiming one of the spurious dependencies is the cause. If there were no spurious dependencies it would report that there were no contexts in error. It needs to be checking for circular refs to properly report the problem.

Here is an example of the incorrect error msg. Here,
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3 depends on:
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink2Bean,service=EJB3 which depends on:
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3.
Both also depend on jboss.ejb:service=EJBTimerService, and the *EjbLink2Bean* also depends on jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3 which is ultimately incorrectly reported to be the root error context.

org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3
 -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-two-ejb.jar,name=EjbLink2Bean,service=EJB3 **}
 -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService **}

jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-two-ejb.jar,name=EjbLink2Bean,service=EJB3
 -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb,name=EjbLink1Bean,service=EJB3 **}
 -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService **}
 -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3,* **}


*** CONTEXTS IN ERROR: Name -> Error

<UNKNOWN> -> ** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3,* **

[starksm64]

I created http://jira.jboss.com/jira/browse/JBDEPLOY-30 as a feature request to improve this.

[alesj]

So, in shorter names, in order not to go blind from all those ejbs:

--> == depends on

First the cycle:
A --> B
B --> A

Additional dependencies:
A --> C
B --> C
B --> D

And you're saying D is reported as the cause?

1) I'll see what we can do with cycles - reporting wise
2) Check why D is the cause, which is really strange

[starksm64]

Yes, D is reported as the cause. It is simply because the logic in IncompleteDeployments.calculateContextsError removes any context that has missing dependencies as root causes. This ultimately leaves D which has no dependencies. In reality D should not be in the missing dependency list, but because the resolution was stopped as soon as the first unresolved dependency was seen it does.

[alesj]

In reality D should not be in the missing dependency list, but because the resolution was stopped as soon as the first unresolved dependency was seen it does.

Yeah, I don't see what D is doing there, since it should be OK.
It shouldn't matter that it is referenced by some other bean as its dependency.
Which resolution you're talking about?

[adrian.brock]

Something like this needs including in the main deployers version of the ICDE
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=69861

[starksm64]

"alesj" wrote:

Yeah, I don't see what D is doing there, since it should be OK.
It shouldn't matter that it is referenced by some other bean as its dependency.
Which resolution you're talking about?

B does have a dependency on D, but it is resolvable. If you look at the AbstractDependencyInfo.resolveDependencies code, it stops looping through the unresolved DependencyItems as soon as the first unresolvable item is seen.

If all resolvable dependencies were processed and then resolveDependencies returned false, only the two cyclic dependencies would remain for the error processing.

[alrubinger]

I'm seeing:

23:04:15,155 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
....

From hard copy deployment, but JMX Deployments are silent and do not report errors.

S,
ALR

[alesj]

"ALRubinger" wrote:
I'm seeing:

23:04:15,155 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
....

From hard copy deployment, but JMX Deployments are silent and do not report errors.

This doesn't tell me anything.
Silent in what way?
e.g. what is the input, what is the expected result, what actually happens, etc...

[alesj]

If all resolvable dependencies were processed and then resolveDependencies returned false, only the two cyclic dependencies would remain for the error processing.

Yup, that's right.
Should we change AbstractDependencyInfo::resolveDependencies to work this way?

Or some additional (quick) isResolved on DependencyItem?
Which would only do some check, not changing the state inside the instance.
e.g.

 public boolean isResolved(Controller controller)
 {
 return isResolved() || controller.getInstalledContext(iDependOn) != null;

 }

which we would then use in DeployersImpl::checkControllerContext

 for (DependencyItem item : dependsInfo.getIDependOn(null))
 {
 if (item.isResolved(controller) == false)

[starksm64]

Unless there was some reason to not attempt all dependencies resolution, then yes, I would say process them by updating resolveDependencies.

[alrubinger]

"alesj" wrote:

"ALRubinger" wrote:
I'm seeing:

23:04:15,155 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
....

From hard copy deployment, but JMX Deployments are silent and do not report errors.

This doesn't tell me anything.
Silent in what way?
e.g. what is the input, what is the expected result, what actually happens, etc...

I'll follow up with a separate JIRA and test case for this.

Error: Unresolved dependencies are not reported when deployed via JMX.

S,
ALR

[adrian.brock]

I'll follow up with a separate JIRA and test case for this.

Error: Unresolved dependencies are not reported when deployed via JMX.

S,
ALR

Isn't that just this TODO in the ServiceDeployer

 /**
 * Create a new ServiceDeployer.
 *
 * @param controller the service controller
 * @throws IllegalArgumentException for a null controller
 */
 public ServiceDeployer(ServiceController controller)
 {
 super(ServiceMetaData.class);
 if (controller == null)
 throw new IllegalArgumentException("Null controller");
 this.controller = controller;
 setComponentsOnly(true);
 // TODO setUseUnitName(true);
 }

i.e. tell the deployment layer which JMX contexts are part of the deployment
so it can do the ICDE properly

[adrian.brock]

Isn't that just this TODO in the ServiceDeployer

You should be able to set that property to true in bootstrap-beans.xml
with your example to test it.

[alrubinger]

You should be able to set that property to true in bootstrap-beans.xml with your example to test it.

Thanks; I actually don't have a *-beans.xml as this use case was from a failed EJB3 deployment.

I'll curb this until I have a concrete example to report such that I'm not wasting anyone's time. ;)

S,
ALR