[jboss-user] [JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

[Kabir Khan]

User development,

A new message was posted in the thread "Pluggable dependency resolver":

http://community.jboss.org/message/524239#524239

Author  : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com

Message:
--------------------------------------------------------------
I got AS trunk started with the indexing dependency resolver, unfortunately I did not see any difference in startup speed worth mentioning :-(
 
So, although we only try to increment the contexts that have actually had a dependency resolved, at the moment there is a lot of work going into determining what those contexts are. Maybe too much?
 
An overview of what I have so far is probably best described with an example. I deploy
 
<bean name="Bean" class="...">
   <property name="prop"><inject bean="Other"/></property>
</bean>


Since this is an explicit dependency on a name which is required in the CONFIGURED state and Other reaches the INSTALLED state, this is recorded in the NameDependencyResolverMatcher under
 
[INSTALLED->["Other"->{Context[name="Bean"]}]
 
(Read as when a bean called "Other" reaches the Installed state, the Context named Bean is a candidate for injection)
 
We then try to push Bean as far through the states as we can, in this case it will stop in the INSTANTIATED state since Other is not available yet when we try to resolve the dependencies to enter Configured.
 
Now if we deploy
 
<bean name="Other" class="…"/>
 
We push this through the states. There is a stateIncremented(ControllerContext) method in the resolver called by the controller whenever a context has its state incremented which calls through to all the dependency resolver matchers. For Other in PRE_INSTALL, …, START nothing is found in the matchers so we just keep on moving Other through the lifecycle. Once stateIncremented(ControllerContext) is called for Other when it hits the INSTALLED state we then check all the dependency resolver matchers. We hit the NameDepedencyResolverMatcher and for INSTALLED we find 
 
["Other"->{Context[name="Bean"]}]
 
We then look up "Other" in this map and find
 
{Context[name="Bean"]}
 
in other words the context called Bean has been waiting for Other to reach the INSTALLED phase, we then check that Bean has its other dependencies resolved and then attempt to push it through the states as before.
 
I have not tried profiling anything yet, but for simple dependencies like the one above I think the above mechanism should be fast. However, there are a few other factors that could well slow it all down. 
 
====== Contextual Injection (and Callbacks) =========
 
If we first deploy
 
<bean name="Bean" class="...">
   <property name="prop"><inject/></property>
</bean>

 
where the type of the prop property is 'interface SomeInterface'. This becomes a ContextualInjectionDependencyItem, and is recorded in ContextualInjectionDependencyResolverMatcher as
 
[INSTALLED->[[interface SomeInterface]->{Context[name="Bean"]}]
 
As before Bean is moved to the INSTANTIATED phase. 
 
Now we deploy
 
<bean name="Bean" class="SomeClass"/>


where SomeClass somewhere in its inheritance hierarchy has SomeInterface as a parent. When installing Bean, each time its state is incremented it checks the matchers for matching contexts. It will find nothing in NameDependencyResolverMatcher nor in ContextualInjectionDependencyMatcher for PRE_INSTALL, …,START. When it gets to INSTALLED, again it finds nothing in  NameDependencyResolverMatcher, but when it hits ContextualInjectionDependencyMatcher it finds this for INSTALLED
 
[interface SomeInterface]->{Context[name="Bean"]}
 
Now it checks if SomeClass is there, nothing. Then do the same for all the superclasses and interfaces until it finally finds the Bean Context under SomeInterface. We then check Bean's other dependencies and push it through the remaining states.
 
I am not sure how extensively contextual injection is used in the AS, but the point here is that if contextual injection is used *at all* and we have contexts registered as waiting for a few other states, whenever other contexts reach one of those states we have to do all the work of looking up all the superclasses/interfaces to see if any of the waiting contexts can be removed.
 
Also, this work is duplicated since we also have a CallbackDependencyResolverMatcher which effectively does exactly the same but for CallbackDependencyItems.
 
====== Scoping =======
 
We only record the dependencies in the matchers for the controller into which the context owning the dependency was installed. If a context has its state incremented, there might be contexts with dependencies on it waiting in one of the child controllers. So the stateIncremented(ControllerContext) method ends up calling stateIncremented(ControllerContext) on all the child controller resolvers as well, which in turn will invoke all the matchers for each child controller.

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/524239#524239