Description Thomas Watson 2011-03-16 17:52:46 EDT

Currently RegionLifecycleListener is pretty limited in what it gets informed about a region.  This appears to only be used as an implementation detail for StandardManageableRegionDigraph and likely is sufficient for that usecase.  I have two thoughts on this:

1)  If RegionLifecycleListener is only an impl detail for the StandardManageableRegionDigraph mbean then perhaps there is no reason to make RegionLifecycleListener API and we can get by with an internal way of informing the mbean about added/removed regions.

2)  There are other operations that can be performed on a region that a region listener may be interested in.  For example:
  a) When bundles are added/removed
  b) When new connections are made between tail->head regions
  c) When connections are severed as a result of removing a region.


We have a few options if we want to fix this:

1) Make RegionLifecycleListener an implementation detail for StandardManageableRegionDigraph mbean and remove it as API.  This allows us to add a different mechanism later as we get a better understanding of what the requirements are for listening to regions.

2) Use EventAdmin and define a event topic for regions we can use to publish region events to.  This is relatively generic and should allow us to easily expand it in the future with what ever events we need.

3) Consider registering each Region as a service to take advantage of service events for delivering events on regions.  When a region is added to the digraph a region service registered event would be fired.  When a region is removed from the digraph a service unregistering event would be fired.  We can then use service properties to track other properties such as bundles included in a region and connections between regions.

The problem with this approach is that a ServiceListener will not really know why a MODIFIED service event is being published (is it because a bundle got added/removed or because a new connection got added/removed?)

4) Enhance RegionLifecycleListener to allow more generic events to be fired.  Right now it has regionAdded/regionRemoving methods.  We could change that to a single method where types can be REGION_ADDED, REGION_REMOVING

 void regionChanged(RegionEvent event)

Where RegionEvent has the following methods:
  TYPE getType() - returns the type of event with the following types define:

REGION_ADDED
REGION_REMOVING
BUNDLE_ADDED
BUNDLE_REMOVING
CONNECTION_ADDED

  Object getProperty(String name);

This is similar to how Events are defined in Event admin where the event has a set of properties associated, for example one property key would be the "region" the event is associated with.  Other keys could hold other information depending on the event type.  For example, "bundle.id" could hold the bundle id being added or removed.



My preference is to do 1) and make this all listener stuff an internal detail of the mbean support.  If that is not acceptable then I think 2) is the most simple, but it places a dependency on EventAdmin.  EventAdmin also complicates things because the event admin impl is not region aware.  Using 3) services is compelling but I think it has a number of oddities because we try to place Region attributes as service properties which may not work very well.  Ultimately 4) may be the best option if 1) is not acceptable.