Java Reference
In-Depth Information
You use the binding method form that supplies the service attributes as a map. You
use the
name
property from the map to figure out which component has been
removed and remove your reference to the service object from the internal map.
Binding method accessibility
You may have noticed that the binding methods you've defined have package-private
visibility. The Declarative Services specification states the following with regard to
method visibility:
■
public
—Access permitted
■
protected
—Access permitted
■
package private—Access permitted if the method is declared in an implementa-
tion class or any superclass within the same package
■
private
—Access permitted if the method is declared in an implementation
class
As a matter of best practice, you should generally protect binding methods, because
doing so prevents external code from injecting services out of band of the main ser-
vice-registry lifecycle (assuming the Java security manager is enabled—we'll look at
security in chapter 14).
Now, let's return our attention to how components describe their service dependen-
cies. So far, we've discussed that the component service dependency description
includes a service interface and binding methods. Other, more sophisticated depen-
dency characteristics are available.
SOPHISTICATED SERVICE DEPENDENCY CHARACTERISTICS
Many service dependencies fall into the category of being a hard dependency on a sin-
gle service object. But what if your component is different? Recall the following snip-
pet from listing 11.3:
<scr:reference
interface="org.foo.shape.SimpleShape"
cardinality="0..n"
policy="dynamic"
bind="addShape"
unbind="removeShape"/>
We haven't discussed the cardinality and policy dependency characteristics yet, but
they help you address more sophisticated service dependency situations. The notion
of
cardinality
plays two roles in the Declarative Services specification:
Optionality
—Cardinality values starting with 0 are treated as optional, whereas
values starting with 1 are treated as mandatory.
■
Aggregation
—Cardinality values ending with 1 are treated as a dependency on a
single service object of the specified type, whereas values ending in n are
treated as a dependency on all available service objects of the specified type.
■
