Java Reference
In-Depth Information
Figure 8.8
Painting with the fixed example
debugging your own
OSG
i applications. In the next section, we'll take a closer look at
a set of problems you'll eventually encounter when using
OSG
i: class-loading issues.
8.2
Solving class-loading issues
OSG
i encourages and enforces modularity, which, by its nature, can lead to class-loading
issues. Maybe you forgot to import a package or left something out when building a bun-
dle. Perhaps you have a private copy of a class you're supposed to be sharing or forgot
to make sure two tightly coupled packages are provided by the same bundle. These are
all situations that break modularity and can lead to various class-loading exceptions. The
right tools can help you avoid getting into these situations in the first place, but it's still
worthwhile knowing what can happen and what the resulting problem signatures look
like. The following sections take you through a number of common class-loading prob-
lems, what to look out for, what might be the cause, and how to solve them.
All the exceptions discussed in this section come from the same example applica-
tion: a simple hub-and-spoke message system that uses the
OSG
i extender pattern (see
section 3.4) to load spoke implementations at execution time. The basic architecture
is shown in figure 8.9. The only thing that changes throughout this example is the
Spoke-Class:
org.foo.spoke.SpokeImpl
Spoke-Name:
some_identifiable_name
Spoke
Receive
Spoke
Receive
Hub
API/SPI
Send
Hub
extender
Spoke
Receive
Hub
tester
Receive
Figure 8.9
Simple hub-and-
spoke message system
Spoke
