On 2/8/2010 3:48 AM, David Jencks wrote:
I've discovered that there's a timing problem using bueprint in
geronimo. Blueprint uses a separate thread to fire up the beans in a
bundle, whereas geronimo uses the calling thread to start a
configuration. This means that if a gbean needs something supplied by
a blueprint bean in an "earlier" configuration, there's no guarantee
the blueprint stuff will have been processed at all yet.
Is your dependency actually on the entire blueprint configuration or on
individual services that the configuration is exporting? It would seem
more appropriate to wait on the dependent service rather than on the
entire blueprint configuration.
A simple way to deal with this is with a WaitForBlueprintGBean that
registers as a BlueprintListener and blocks until it gets a
BlueprintEvent indicating that the blueprint stuff either started or
failed to start.
While all comments are welcome, I'd appreciate it if Jarek or Rick
could take a look to see if I missed any events that need to be
considered. The new class is
framework/modules/geronimo-blueprint/src/main/java/org/apache/geronimo/blueprint/WaitForBlueprintGBean.java
I put this in a new module since we may not want a dependency on
blueprint-api for every module in geronimo. The only other place that
seems reasonable to me is geronimo-system but this will drag in
blueprint everywhere.
Anyway..... with the help of this gbean, slightly modified aries
blueprint, xbean-blueprint, karaf modified to use aries blueprint, and
a couple minor activemq changes to eliminate needless spring-isms, I
appear to have an activemq broker starting up under blueprint, and our
regular activemq-ra connector starting. I plan to work on getting all
these bits committed or into patches.
thanks
david jencks
