Java Reference
In-Depth Information
and is
public
because it's used by other packages in the bundle. You need to export the
org.foo.service
package, but you don't want to expose the
Util
class. In general, you
should avoid such scenarios, but the following metadata snippet illustrates how you can
do this with export filtering:
Export-Package: org.foo.service; version="1.0.0"; exclude:="Util"
This exported package behaves like any normal exported package as far as dependency
resolution is concerned; but at execution time, the framework filters the
Util
class
from the package so importers can't access it, as shown in figure 5.7. A bundle attempt-
ing to load the
Util
class receives a “class not found” exception. The value of the direc-
tive specifies only class names; the package name must not be specified, nor should the
.class portion of the class file name. The
*
character is also supported as a wildcard, so
it's possible to exclude all classes with names matching
*Impl
, for example.
A
B
Util
public org.foo.service.Service
public org.foo.service.U
til
org.foo.service.ServiceImpl
export
org.foo.service
version="1.0.0"
exclude:=Util
import
org.foo.service
version="[1.0.0, 2.0.0)"
Figure 5.7
Bundle A exports the
org.foo.service
package but excludes the
Util
class. When bundle B imports the
org.foo.service
package from bundle A, it can only
access the public
Service
class.
In some cases, it may be easier to specify which classes are allowed instead of which
ones are disallowed. For those situations, the
include
directive is available. It specifies
which classes the exported package should expose. The default value for the
include
directive is
*
, and the default value for the
exclude
directive is an empty string. You
can also specify both the
include
and
exclude
directive for a given exported package.
A class is visible only if it's matched by an entry in the
include
directive and not
matched by any entry in the
exclude
directive.
You should definitely strive to separate your public and private
API
s into different
packages so these mechanisms aren't needed, but they're here to get you out of a
tough spot when you need them. Next, we'll move on to another mechanism to help
you manage your
API
s.
5.1.5
Duplicate exports
A given bundle can see only one version of a given class while it executes. In view of
this, it's not surprising to learn that bundles aren't allowed to import the same pack-
age more than once. What you may find surprising is that
OSG
i allows a bundle to
export
the same package more than once. For example, the following snippet of meta-
data is perfectly valid:
Export-Package: javax.servlet; version="2.3.0",
javax.servlet; version="2.4.0"
