User development, A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524424#524424 Author : Kabir Khan Profile : http://community.jboss.org/people/[email protected] Message: -------------------------------------------------------------- Right, So the basic outline is that AbstractController.install(ControllerContext) installs the contexts into the controller. In doing so the context goes through several states. Upon entry to each state, the controller checks if the context has all its dependencies resolved, and if so it is moved to the next state. If not, it is left in that state, and we try to resolve the context later once another context is added to the controller. Once the context reaches INSTALLED state it is considered to be installed. The mechanism that is currently in trunk does this by calling a method internally in resolveContexts(). What this essentially does is to iterate over each controller state. For each controller state it gets a list of the contexts in that state and then for each context see if the dependencies are resolved. The contexts with all dependencies resolved are pushed to the next state, and the contexts that don't are left in the current state. If at least one context could be moved to the next state, we iterate over the states again. Pseudocode: resolveContexts() { while (resolved) { resolved = false; for (ControllerState state : statesInController) { Set<ControllerContext> contexts = getContextsForState(state); Set<ControllerContext) resolvedContexts = new HashSet<ControllerContext>(); for (ControllerContext context : contexts) { //Req. state will normaly be INSTALLED so we don't look at the contexts that have reached that state if (state == context.getRequiredState()) continue; //Iterate over context's DependencyItems and try to resolve them //(they are resolved by looking up the information from the DependencyItem in the controller) if (isResolved(context), state) { resolvedContexts.add(context); } } if (resolvedContexts.size() > 0) { for (ControllerContext context : contexts) incrementState(context); // Puts the context's state to state, and invokes any associated ControllerContextAction resolved = true; break; } } } } So basically every time a context has its state incremented there could potentially be other contexts waiting for it to enter that state via a dependency which is why we go over and check all the contexts in each state. With my indexing resolver I take a different approach. When adding a context to the controller I index it by its dependencies. Then later when adding another context, I look in the index if something has an indexed dependency on the new context. If that is the case, I only try to increment the state of the contexts registered as having a dependency. Some basic profiling (take with a pinch of salt) shows that not that much time is spent actually trying to resolve dependencies with either way of doing it. Having spoken about this with Ales, the reason for this is that most stuff deployed in AS is deployed in the right order or more or less at the same time as their dependencies, so we don't have HUGE numbers of contexts waiting in a state while hoping to reach INSTALLED. If that were the case I am pretty confident that the indexing resolver would win easily. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/524424#524424
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
