Java Reference
In-Depth Information
protected void deactivate() {
SwingUtils.invokeLater(new Runnable() {
public void run() {
WARNING Be careful about using services in the @Invalidate callback,
because service departure is the likely cause of the invalidation. This means
not all service references are necessarily usable.
Callback methods such as these are nice if you want your components hooked into
their own lifecycle. But what if you want them to actively participate in it?
In addition to lifecycle-callback methods, i POJO components can directly participate
in their own instance and service-lifecycle management using the @Controller and
@ServiceController annotations, respectively. Both of these annotations can be asso-
ciated with a boolean member field in the component. For example:
public class MyComponent implements MyService {
private boolean isValid = true;
This tells the i POJO runtime to monitor this field to control the lifecycle of the compo-
nent. If the component sets isValid to false , i POJO invalidates the component
instance and throws it away. You can use this approach to model exceptional condi-
tions, such as an invalid configuration with no reasonable defaults.
@ServiceController is a little more dynamic and allows the component to control
when its provided services are published:
public class MyComponent implements MyService {
private boolean isProvided = true;
In this case, if the component sets isProvided to false , the i POJO runtime removes
the instance's service from the service registry. If isProvided is set to true again,
i POJO publishes the service into the service registry again. You can specify the precise
service interface using the specification annotation attribute, if the component
provides more than one service. By default, @ServiceController applies to all pro-
vided services.
As with the other component frameworks, you can access the underlying OSG i
BundleContext object associated with the bundle containing the components. In
Search WWH ::

Custom Search