Building dynamic applications with OSGi services - Enterprise OSGi in Action - page 142

specifically designed for OSG i, and there isn't a specification describing it. Some of the
more advanced features that are present in other OSG i dependency injection models
are missing, or are more difficult to use than if they'd been designed in at the start.
A mix-and-match principle applies to any of the OSG i service-based injection
frameworks we've described. If you want one of your modules to run outside of OSG i,
but want to take advantage of Blueprint's tight integration with the rest of the Apache
Aries runtime, you can use Blueprint for most of your bundles and Peaberry in the
module that needs to run elsewhere. Regardless of which implementation you choose
to use, underneath they are all using normal OSG i services, so compatibility is guaran-
teed. Alternatively, if you like Blueprint's tidy handling of OSG i dynamics, you could
consume services using Blueprint but publish them using iPojo, or any other frame-
work, or even register them programmatically.
Covering Declarative Services, iPojo, and Peaberry in detail is beyond the scope of
this topic; although these frameworks have many nice aspects and distinct advantages
over Blueprint in some contexts, we think that Blueprint is the framework most suited
to enterprise programming. Even though you've seen quite a bit of Blueprint already,
it has lots of sophisticated features that we haven't had a chance to explore yet. Let's
have a look at some of this extra power in more detail.

6.3 Getting the most out of Blueprint

As you've been writing the Fancy Foods application, we've been demonstrating the most
important bits of the Blueprint syntax. But Blueprint is a rich specification language, and
there's lots more to it than what you've seen so far. We won't cover all the dark corners
of the Blueprint syntax in this chapter, but we'll show you a few more capabilities.

6.3.1 Using Blueprint for things other than services

Although we've been talking about Blueprint as a tool for managing OSG i services, it
can do a lot more than register and inject services. If you're used to programming in
core OSG i, you may have some jobs that you automatically do with a BundleActivator .
(If you're used to Java EE programming, you might be using static factories to do the
same sorts of jobs.) All of this is still possible in enterprise OSG i, but we're firmly con-
vinced that it's easier, cleaner, and better using Blueprint.
For example, an eager singleton bean can play the role of a bundle activator. The
main difference is that a bean has much more flexibility in terms of its interface
because a bundle activator has to implement BundleActivator , whereas a Blueprint
bean can implement whatever it likes (or nothing at all).

WARNING: WIRING WITHIN A BUNDLE One area where Blueprint is useful but
OSG i services shouldn't be used is for wiring within a bundle.

One good reason for this is that services are public; unless you want the entire
framework to see your internal wiring, you should keep it out of the Service
Registry.