Chapter 4. In-depth look at bundles and services

 

This chapter covers

  • Keeping bundle packages private to decrease exposure
  • Making bundle packages optional to improve flexibility
  • The wiring API
  • Understanding class loading in a bundle
  • Advanced use of service filtering
  • Service prioritization
  • Service factories
  • Unit testing and integration testing for robustness

In chapter 3, we developed our first OSGi-based application employing two important OSGi features: bundles and services. As you’ve seen, bundles allow you to modularize your code, which lends to better reuse of code. Likewise, services improve the decoupling between the bundles, which yields a more resilient and flexible system architecture.

In this chapter we’ll take an in-depth look into several patterns and techniques that will help us develop better decoupled, flexible, and extensible bundles and services for our OSGi applications. We’ll start our discussion by looking into how to minimize the dependencies between the bundles we create and use.

4.1. Restricting a bundle’s export contract

In object-oriented programming, you learn that you should keep the signature of a class as restrictive as possible. This is done, for example, by first annotating a method of a class as private, and if that’s not possible, making it protected, and only if absolutely necessary making it public.

4.2. Expanding a bundle’s export contract

4.3. Packages as requirements and capabilities

4.4. Avoiding the dreaded class-hell problem

4.5. Understanding OSGi’s class loading

4.6. Decoupling bundles using services

4.7. Improve robustness by testing your applications

4.8. Summary