For the removeIDependOn() it is because the DescribeAction is buggy :-)

It should be removing the dependency items in uninstall()
that it added in install() from the AOP dependencies.

Of course, nobody noticed because all that would happen is that
the dependencies would be resolved multiple times if the context is re-installed.

Besides that case, there are no other occurances of dynamic dependencies
that I can think of?
i.e. Where a dependency is added that should be removed before the
context is uninstalled from the controller.

The other possible example would be that in principle a user can
create their own ControllerContext and reuse the AbstractDependencyInfo.
They may want to abitrarily add/remove dependencies?

e.g. The JMX controller does the first part (creates a ServiceControllerContext)
but it has no requirement to remove dependencies. :-)

For the dependsOnMe it is NOT being maintained properly.

Again, this probably doesn't matter, since it is only used when you remove a context.
See ControllerContext.uninstall()

IIRC the reason I don't maintain it is because the only place to do so
could be too early. i.e. in the DependencyItem.resolve() implementations.

If we removed it at that point, we have only just determined that the dependency
is no longer resolved, the controller hasn't had chance to act on that information
yet and so the uninstall() may not work correctly?

It is certainly something that we should look at tidying up.

Shows up again in

https://jira.jboss.org/jira/browse/JBCL-119

Also shows up in something Carlo pointed out.

All tests pass with the below change which I have committed against https://jira.jboss.org/jira/browse/JBKERNEL-84. However, I do see a few warnings like this when running KernelAllTestSuite due to DemandDependencyItem not having its iDependOn set. Any ideas on making this more flexible? I kind of wish DependencyItem would record its dependencies somehow...

29221 WARN  [AbstractKernelController] Problem finding dependency for AbstractDemandMetaData$DemandDependencyItem@4946101f{name=bean depends

On=null whenRequired=Instantiated resolved=false demand=foobar}

java.lang.IllegalArgumentException: Null name

at org.jboss.dependency.plugins.AbstractController.getContext(AbstractController.java:520)

at org.jboss.kernel.plugins.dependency.AbstractKernelController.getContext(AbstractKernelController.java:150)

at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1477)

at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1391)

at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:704)

at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:617)

at org.jboss.test.kernel.lazy.test.LazyInstantiationTest.testLazy(LazyInstantiationTest.java:109)

Index: dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java

===================================================================

--- dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (revision 100075)

+++ dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (working copy)

@@ -1459,7 +1459,40 @@

                   }

                }

             }

-           

+

+            Set<DependencyItem> iDependOn = dependencies.getIDependOn(null);

+            if (iDependOn.isEmpty() == false)

+            {

+               for (DependencyItem item : iDependOn)

+               {

+                  if (item.isResolved())

+                  {

+                     ControllerState whenRequired = item.getWhenRequired();

+                     if (whenRequired == null || whenRequired.equals(fromState))

+                     {

+                        if (item.unresolved(this))

+                        {

+                           try

+                           {

+                              ControllerContext dependency = getContext(item.getIDependOn(), item.getDependentState());

+                              if (dependency != null)

+                              {

+                                 DependencyInfo info = dependency.getDependencyInfo();

+                                 if (info != null)

+                                 {

+                                    info.removeDependsOnMe(item);

+                                 }

+                              }

+                           }

+                           catch(RuntimeException e)

+                           {

+                              log.warn("Problem finding dependency for " + item, e);

+                           }

+                        }

+                     }

+                  }

+               }

+            }

          }

          catch (Throwable error)

          {

To avoid the stack trace, I have changed it to this:

                              //FIXME DemandDependencyItems have a null iDependOn
                              if (item.getIDependOn() == null)
                              {
                                 log.warn("Null iDependOn for " + item);
                              }
                              else
                              {
                                 ControllerContext dependency = getContext(item.getIDependOn(), item.getDependentState());
                                 if (dependency != null)
                                 {
                                    DependencyInfo info = dependency.getDependencyInfo();
                                    if (info != null)
                                    {
                                       info.removeDependsOnMe(item);
                                    }
                                 }
                              }
 

alesj wrote:

 

Flexible in what way?

 

Why would you record something you can/should get from the existing info?

Take this example:

1) deploy Context A of class MyClass

2) deploy Context B with BY_CLASS dependency on MyClass, and so gets injected with ContextA

so far so good

3) deploy Context C of class MyClass, deploys fine

4) undeploy Context B, which then calls getContext(MyClass). However, now there are two contexts of type MyClass so this call fails.