Java Reference
In-Depth Information
Creating a framework instance
It's great to have a standard interface for framework implementations, but you can't
instantiate an interface; you need a way to get a concrete implementation class. It isn't
possible for the OSG i specification to define a standard class name, so it adopts the
standard Java approach of specifying service-provider implementations in JAR files:
META-INF /services.
In this case, META-INF /services refers to a directory entry in a JAR file. Just as a
JAR 's META-INF / MANIFEST . MF file contains metadata about the JAR file, so does its
META-INF /services directory. More specifically, it contains metadata about the service
providers contained in a JAR file. Here the term service isn't referring to an OSG i ser-
vice, but to well-known interfaces and/or abstract classes in general. All in all, the con-
cept is similar to the OSG i service concept.
The META-INF /services directory in a JAR file contains service-provider configura-
tion files, which refer to a concrete implementation class for a given service. Concrete
service implementations are connected to their abstract service type via the name of
the file entry in the directory, which is named after the fully qualified service it imple-
ments. For example, a service implementation for the java.text.spi.DateFormat-
Provider service would be named
The content of this file is the name of the concrete service-implementation class:
Figure 13.1 depicts this hypothetical example. At execution time, when a service pro-
vider is required, the code needing it queries the service-provider configuration file
.. public class CustomDateFormatProvider
implements DateFormatProvider {
Figure 13.1 The Java META-INF/services approach dis-
covers service providers at execution time by performing
lookups of well-known named resource files to acquire
concrete service-implementation class names.
Search WWH ::

Custom Search