Dependencies from scoped to global

[kabirkhan]

I have a bean installed in a scoped controller, which has a dependency on a bean in the global controller. If I try to install the scoped bean first, it correctly waits until I have installed the global bean. But when I undeploy the global bean, it does not stop the scoped bean. Presumably because the main controller does not look in the child controllers, and there is no information in the DependencyItems returned by DependencyInfo.dependsOnMe as to which controller it should look for the item in.

Unless you know what I have said above is wrong, I can try to reproduce with a test case.

[alesj]

Unless you know what I have said above is wrong, I can try to reproduce with a test case.

I know what the problem is.
The problem is simple :-),
it's the solution that is not that trivial. :-(

The issue is that when you do install,
the underlying controller used in that dependency item resolution is scoped,
but when you do uninstall

 Set<DependencyItem> dependsOnMe = dependencies.getDependsOnMe(null);
 if (dependsOnMe.isEmpty() == false)
 {
 for (DependencyItem item : dependsOnMe)
 {
 if (item.isResolved())
 {
 ControllerState dependentState = item.getDependentState();
 if (dependentState == null || dependentState.equals(fromState))
 {
 if (item.unresolved(this))
 {
 ControllerContext dependent = getContext(item.getName(), null);
 if (dependent != null)
 {
 ControllerState whenRequired = item.getWhenRequired();
 if (whenRequired == null)
 whenRequired = ControllerState.NOT_INSTALLED;
 if (isBeforeState(dependent.getState(), whenRequired) == false)
 uninstallContext(dependent, whenRequired, trace);
 }

the controller (see 'this') is not scoped,
hence has no clue about scoped bean (dependent == null).

Dunno what kind of quick hack could fix this. :-)

[kabirkhan]

I think/hope this is the last hurdle for me to get scoped aop working. Deploy works fine, undeploy doesn't as described above.

Here's a quick hack for you :-) For my use case the scoped bean is an aop interceptor, and the global is a bean that gets injected into the interceptor. The interceptor is installed into a scoped controller by the aop deployer with a unique prefix/name. So we could look at the child controllers for a bean with that name if this call returns null.

ControllerContext dependent = getContext(item.getName(), null);

This would work for aop, but could break other things if names are not unique. You did however recommend unique names due to shortcomings in AbstractController.uninstall(), so "other things" using scoping might be broken anyway?

I'm not familiar with this part of the code, so the rest of this post is me guessing :-) Who populates DependencyInfo.dependsOnMe? I would assume it happens when describing the side who has the dependency? i.e. the scoped bean who has a dependency on the global one? If that is correct, could/should not the controller be known for the dependencies?

[alesj]

Who populates DependencyInfo.dependsOnMe? I would assume it happens when describing the side who has the dependency? i.e. the scoped bean who has a dependency on the global one? If that is correct, could/should not the controller be known for the dependencies?

Yes, it's the dependency item when it gets resolved.
We could hold the ref to controller but we don't.
It should be some other better way to resolve this.
Keeping DependencyItem simple as possible,
only holding the minimum info needed - name, dependOn, when required, state.

[kabirkhan]

Registering it in the child controller somehow so it can be used for a lookup if it cannot be found in current or parent controller?

[kabirkhan]

I have attached a pacth to https://jira.jboss.org/jira/browse/JBMICROCONT-341

[alesj]

I have attached a pacth to https://jira.jboss.org/jira/browse/JBMICROCONT-341

I applied your patch, though it was broken.
Hence modified version of it. ;-)

The tests now pass,
but we should look into how to make this more natural.