On Feb 8, 2010, at 4:36 AM, Rick McGuire wrote:
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.
In this case the activemq-ra is looking for a server socket opened by
an anonymous nested bean in the xbean plan.
I actually don't agree that waiting for individual blueprint beans is
more appropriate. The WaitForBlueprintGBean has to go in the same
geronimo plugin as the blueprint plan, and it has the effect of making
blueprint startup act the same as gbean plugin startup. As long as we
keep gbean/plugin startup in the same thread as whatever asked the
plugin to start, this is going to be much more reliable than trying to
mix timing models.
In this particular case there's another possible solution that would
be very desirable to implement.... the activemq-ra is trying to open a
connection to the broker to do recovery. It would be even better to
fix the transaction manager to keep trying recovery until it can
successfully get a connection. However I think getting the timing
models to be more compatible will prove useful in a lot of places. I
think I'm seeing occasional jndi startup failures that may well be a
similar timing issue.
thanks
david jencks
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
