1:08 p.m.
JBoss 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