bjhargrave
commented
7 years ago Comment author: @rinswind
An example typical for a whiteboard component:
-
Use annotations to code the component. Due to the nature of reflection methods like Class.getDeclaredMethods() do not return Methods in a predefined order. Therefore the
elements in the generated XML are in random order. -
Declare dynamic greedy policy for the whiteboard service reference.
-
In bind() process a whiteboard service instance. Often this requires state that needs to be prepared by activate(). Often this requires services that are bound with static policy. E.g. use EventAdmin to post events about important stages of the processing.
-
In unbind() unprocess a whiteboard service instance Again this often requires static services and/or state prepared by activate().
The most natural way to code such a whiteboard fails. When bind/unbind are called sometimes the static services are not present and always the state prepared by activate() is not setup. As a result a more complex pattern needs to be implemented.
-
Shift all the logic from bind/unbind into internal methods.
-
In bind() Add the service to a collection. Except the service properties may also be needed so add to something more complex that can store both. Check if the component is active. If so call internal process().
-
In unbind() Do the reverse of bind. Remove from collection, check flag, if active call internal unprocess().
-
In activate() Set a flag marking the component as active. Call process() all services from the internal list.
This pattern is so common that it is worth for the specification to support it directly. I.e. in section 112.5.6 of the enterprise spec change the activation order to:
- Load the component implementation class.
- Create the component instance and component context.
- Bind the target services which use static policy.
- Call the activate method, if present.
- Bind the target services which use dynamic policy.
Original bug ID: BZ#2984 From: @rinswind Reported version: R7