[jboss-dev-forums] [Design the new POJO MicroContainer] - Bug in Microcontainer - Errors from DependencyInfo/Item

[adrian@jboss.org]

I've found a bug in the MC where if a DependencyItem.resolve()
throws a RuntimeException that error doesn't get handled.

It is propogated out to whoever did the install()/change()
and further resolution stops.

I don't think it leaves anything in an inconsistent state, but it does
mean that everytime tries to install()/change() something
(regardless of whether it is related to the context in error)
they will get that error back.

For the case I found, the fix is (which I will commit)


  | Index: dependency/src/main/org/jboss/dependency/plugins/AbstractController.java
  | ===================================================================
  | --- dependency/src/main/org/jboss/dependency/plugins/AbstractController.java    (revision 75590)
  | +++ dependency/src/main/org/jboss/dependency/plugins/AbstractController.java    (working copy)
  | @@ -1017,8 +1017,18 @@
  |              if (advance(ctx))
  |              {
  |                 DependencyInfo dependencies = ctx.getDependencyInfo();
  | -               if (dependencies.resolveDependencies(this, state))
  | -                  result.add(ctx);
  | +               try
  | +               {
  | +                  if (dependencies.resolveDependencies(this, state))
  | +                     result.add(ctx);
  | +               }
  | +               catch (Throwable error)
  | +               {
  | +                  log.error("Error resolving dependencies for " + state.getStateString() + ": " + ctx.toShortString(), error);
  | +                  uninstallContext(ctx, ControllerState.NOT_INSTALLED, trace);
  | +                  errorContexts.put(ctx.getName(), ctx);
  | +                  ctx.setError(error);
  | +               }
  |              }
  |           }
  |        }
  | 

Which treats the error from the DependencyInfo as a normal installation
failure and moves that context to the error state.
It then continues with other contexts.

But this needs validating for all "callouts" to DependencyInfo
and tests written for a "poison" DependencyInfo/Item implementation
to make sure it doesn't cause the repeated error problem I described above.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163502#4163502

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163502