Having read the information in this section, you'll likely agree that structuring a bun-
dle isn't too difficult. The skills you've developed writing Java objects are completely
transferable, and once you get a feel for it you'll recognize a bad bundle in seconds.
One important gotcha, which might seem perfectly innocuous and could easily be
missed, is the cause of some of the most awkward headaches in OSG i development.
This problem is called the split package .
THE PROBLEM WITH SPLIT PACKAGES
A split package is what you have when two bundles contain and export different bits of
the same package at the same version. Although OSG i is well equipped to handle cases
where the same package is exported by several bundles, the assumption is that the pack-
age implementations are interchangeable. Particularly, if two bundles export the same
package at the same version, the OSG i framework could wire you to either. Importantly,
the framework will only ever wire an importing bundle to one of the exported packages.
When a split package isn't a split package
If a bundle imports a package and contains extra bits of that package without export-
ing it, it isn't a split package. This is known as shadowing . Shadowing can cause as
much of a mess as split packages, if you're not careful. We'll discuss shadowing
more in a moment.
This works well when the packages are indeed interchangeable, but it can produce
unexpected effects when different bundles claim to export the same package but con-
tain different classes. Only the classes from the bundle you wire to will be visible at
runtime! See figure 5.4.
Figure 5.4 An importing bundle can only wire to a single instance of an exported package. If this
client needs fancyfoods.split.Foo , then you have a 50:50 chance of success. If it needs both
fancyfoods.split.Foo and fancyfoods.split.Bar , then it can never work.
Search WWH ::