Coping with the non-OSGi world - Enterprise OSGi in Action - page 309

If you're wondering what the requirements and capabilities are, they're the same ones
we introduced in chapter 7. Although they look long-winded in the manifest, they're a
robust way of ensuring that the necessary infrastructure is available, and also configur-
ing that infrastructure at the same time.
Apache Aries has a project known as SPI Fly, which is one of the inspirations for the
OSG i Service Loader Mediation Specification. SPI Fly uses a simpler mechanism to reg-
ister services. For example, to process all META-INF /services files in a bundle, all that's
needed is the following header:

SPI-Provider: *
A full discussion of SPI Fly and service loader mediation is beyond the scope of this
topic, but we hope this introduction will point you in the right direction if you do
encounter this Java SE pattern. There's one more Java technology that can cause seri-
ous problems when moved into OSG i: Java serialization.

12.2.4 Serialization and deserialization

Most Java developers are at least vaguely familiar with Java's support for serialization.
Serialization is the process by which live Java Object s can be persisted, or transported,
in a standard interchangeable binary data format. Serialization is supported by the
base Java runtime, and because of this you might expect things to work as easily in
OSG i as they do elsewhere. To an extent this is true, but there are some potentially
thorny issues.

SERIALIZATION IN OSGI
Serialization in OSG i is a relatively simple process, and does work more or less exactly
like the serialization process in Java SE . A serializable Object can be passed to an
ObjectOutputStream , at which point the entire Object graph connected to that one
Object is also serialized. This is no different from Java SE .
Writing serializable objects in OSG i is a little more difficult than in normal Java,
primarily because it's not possible to serialize objects like BundleContext s or OSG i ser-
vices. The dynamic nature of these Object s means that they can't be relied upon to be
recreated when Object s are later deserialized. On the whole this isn't too big an issue,
particularly for libraries that weren't using OSG i services in the first place.
One of the biggest problems with serializing objects in OSG i is that the graph of
connected Object s doesn't necessarily come from one bundle. There must be a con-
sistent class space, but fields in one object may refer to private implementation types
from other bundles. This doesn't cause a problem at the time of serialization; the seri-
alization code in the virtual machine knows all of the implementation types and can
easily handle the object graph.
Given that the object graph can be serialized, even when private implementation
types are stored as fields, why is there a problem? The issue in an OSG i framework is at
deserialization time. When a bundle tries to read an object from an ObjectInput-
Stream , the underlying runtime needs to load all of the types in the object graph that