Be careful, though—even relatively static applications aren't completely free from
OSG i dynamics. Even if your application never changes after it's installed, there will be
a period during server startup and shutdown when not every service is available to
everyone who might want it. In general, the OSG i bundle start order is undefined, so
your services may not appear in the order you expect.
The good news is that Blueprint insulates you from almost all of this uncertainty,
both during bundle startup and later, during runtime.
STARTUP AND GRACE PERIOD
When a bundle starts, there's no guarantee that other bundles within the applica-
tion that it requires have already been started. (The start order on your test system
may end up being quite different from the start order on the customer's produc-
What happens when a bundle declares Blueprint beans that depend on services
from other bundles, but those services aren't there? Starting the bean anyway and
hoping the services appear before the bean tries to use them would be rash. In this
position, Blueprint allows a grace period for the required services to appear.
Each bundle that defines Blueprint components has its own Blueprint container.
(This is probably at odds with your mental model, which may have a single Blueprint
container for the whole system.) The Blueprint container for a bundle won't start
unless all the mandatory dependencies are available.
By default the Blueprint container will wait five minutes for all required services to
appear. You may see messages relating to GRACE_PERIOD in the log during this time
(see figure 6.6). If all the required services don't appear, the container won't start for
the dependent bundle. You can change the duration of the grace period if you want
things to fail more quickly, or even eliminate it entirely, but we can't think of any good
reasons why you'd want to do that!
The Blueprint container reporting that it's waiting for a Blueprint dependency to become
Search WWH ::