JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521080#521080 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- After a false start with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dep... I now have something working with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dep... .   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. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521080#521080