After a false start with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dependency/src/main/java/org/jboss/dependency/plugins/resolver/IndexingDependencyResolver.java I now have something working with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dependency/src/main/java/org/jboss/dependency/plugins/resolver/IndexingDependencyResolver2.java .

Most tests in the dependency project pass with this, apart from

• BadDependencyTestCase - probably since the calls it checks for now happen differently
• OnDemandDependencyTestCase.testChangeDependencyReinstall() - since the ordering is now slightly different

What I have so far is quite simple. I am still playing around at the moment, and it needs a lot of tidying up, but here is the basic idea:

When calling Controller.install(ControllerContext) the context's dependencies are indexed in the resolver. I put it in a map where the

key is the dependency name, the value is a map where the

key is the dependent state, and the value is list of controller contexts.

Controller.uninstall() removes the context's dependencies from the mentioned map.

AbstractController.resolveContexts(boolean) has been modified to AbstractController.resolveContexts(ControllerContext, boolean) where the context being installed via Controller.install() or Controller.change() is the parameter. This delegates on to the IDR2.resolvePlugins will try to install the context in question as far as it can until it no longer can resolve the dependencies for entering a particular state. Once it cannot go to another state, it simply returns.

I have added a DependencyResolver.stateIncremented(ControllerContext, boolean) callback that is called by the controller once a context has successfully entered the new state. So for example when a context enters the INSTALLED state, this callback is called, and the dependency map is checked for any entries for the context's name and aliases. Then the dependency map is checked for the contexts waiting for that dependency to enter that state. If there were some contexts waiting, we call resolveContexts() on those dependencies.

In addition there is a bit of extra housekeeping for OnDemand contexts.

So far I have not yet looked at scoping, and need to come up with a way to handle implicit dependencies such as supply/demand, contextual injection with qualifiers and so on. Running the kernel project I get 47 failures and 47 errors out of 1575 tests with the new DependencyResolver, which should be fixed once I implement what I have just mentioned.

I'll make which resolver is used configurable via a system property. Once this is more stable we want to run all the tests for any DependencyResolver. For the dependency project I can just create additional sub classes for the different resolvers, but for kernel that will be a big job since there are so many classes, so I'll look at doing profiles instead. For the dependency project I can just create additional sub classes for test for the different resolvers, but for kernel that will be a big job since there are so many test classes, so I'll look at using maven profiles instead.

I've moved things around a bit. The new stuff now lives in https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dependency/src/main/java/org/jboss/dependency/plugins/resolver/indexing/.

I have added scaffolding to support different types of dependency lookups. So far, I have only implemeted the name/alias based one, which is just what I had before in a different place.

The basic idea is that for each kind of dependency item there is an implementation of ResolverMatcher / ResolverMatcherFactory. When indexing a context's dependencies, if the dependency is of type AbstractDependencyItem, the name/alias based one I mentioned is used. I'll implement matchers for when the dependency is a demand or a contextual injection dependency. I'm not 100% happy with needing to implement ResolverMatcher(Factory) for each kind of dependency item, but it is the only idea I have at the moment.

Thomas,

For now I am working on making the main dependency resolution algorithm pluggable and supplying an optimized version. Once that is done, I will look into your requirements

I noticed that some test where dependency items come from annotations were failing, so I have fixed that by adding a dependency item DependencyInfo decorator that tracks when dependency items are added/removed and pushes those to the index.

KernelAllTestSuite now has 45 errors and 37 failures. Next I'll look at the indexing other types of dependency such as Supply/Demand and contextual injection

Looking at supporting contextual injection in the indexing dependency resolver, I've stumbled upon an issue. The basic idea is simple, record which contexts depend on a given Class. When installing a context, check which contexts depend on it (and its superclasses + interfaces) and increment those.

The problem is how to know the class of the context being installed?

• KernelControllerContext.getBeanInfo() - do we want to require it to be a KCC?
• ControllerContext.getTarget() - will not be valid until INSTANTIATED, but then again it probably does not make sense to have contextual injection with a lesser state, although I am not sure this is checked anywhere.

I have got contextual injection and basic supply/demand working, so KernelAllTestSuite is down to 18 errors and 32 failures, most of which are related to scoping.

The supply/demand implementation is pretty simple so far. When registered, if a context has demand dependency items, they get recorded. When a context has supplies and its state is incremented, we try to resolve the contexts with demand di's waiting for that state. I hope that will suffice, since I don't want to get involved with the matchers, I might be wrong but I don't think they lend themselves to hash lookups - I would have to iterate over all of them anyway.

Similarly, the contextual injection mechanism is also quite light, we only index the wanted class on registring, and on incrementing the state we check for the classes. I don't do anything about the qualifiers.

One thing I think we're lacking is "wrong order" tests for contextual injection, at least with qualifiers, so I need to add some. The same might be the case for supply/demand, which I need to check.

I've been using concurrent collections in my DependencyResolver and Matchers, which might not be necessary. I thing al the access to the DependencyResolver + Matchers happens with the controller lock taken, but again I need to check that.

alesj wrote:

 

I had something simpler in mind, not "indexing" per DependencyItem type.

 

Something in the lines of:

(a) install/move context

(b) find it's dependencies

Here, I think you mean the dependsOnMe dependencies, I'll look into that

Just to be clear, we don't check all the contexts the way I have set it up either

I don't think dependsOnMe will work.

If we have a context A and context B depends on that. If we install context B first, and then install context A, context A's dependsOnMe does not get populated until we resolve context B's iDependOn items. There is nothing there to tell us which contexts to try to resolve, so we need to look at all contexts to do it this way.

Have I got the wrong idea/am I missing something?

I have added some simple scoping handling, which brings KernelAllTestSuite down to 11 errors and 24 failures.

Adding simple callback item handling further brings this down to 11 errors and 17 failures.

I've further extracted how the on demand dependencies are handled in the legacy and new model, which brings the total errors in KernelAllTestSuite down to 10. These are in:

• ScopingAliasTestCase
• ScopingAliasAPITestCase
• ScopingOverrideTestCase
• ScopingDependencyTestCase

By the way, if anybody wants to try this out, you switch the dependency resolvers in DependencyResolverAbstractFactory.java. Currently it looks like this:

public class DependencyResolverAbstractFactory
{
   private static final DependencyResolverAbstractFactory INSTANCE = new DependencyResolverAbstractFactory(); 
   private static final DependencyResolverFactory factory;
   static
   {
      //TODO configure with system properties

//      String name = "org.jboss.dependency.plugins.resolver.standard.StandardDependencyResolverFactory";  //1
//      String name = "org.jboss.dependency.plugins.resolver.indexing.IndexingDependencyResolverFactory";  //2
      String name = "org.jboss.kernel.plugins.resolver.indexing.IndexingKernelDependencyResolverFactory";  //3

• 1 is the legacy resolver and all tests pass with that
• 2 is the new resolver used for the dependency project
• 3 is the new resolver used for the kernel project