[ecf-dev] IHostContainerSelector fix

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Folks,

Shortly after release of ECF 3.5's impl of Remote Service Admin (RSA) I 
realized that the API for IHostContainerSelector was not sufficiently 
general (isn't that how it always happens? :).

Specifically, here's the signature of the only method in 
IHostContainerSelector

    IRemoteServiceContainer[] selectHostContainers(
            ServiceReference serviceReference, String[] exportedInterfaces,
            String[] exportedConfigs, String[] serviceIntents);

RSA's exportService, however, has both a ServiceReference and a 
Map<String,Object> that allows the properties on the ServiceReference to 
be overridden...i.e. here is the OSGI RemoteServiceAdmin exportService 
method signature:

    Collection<ExportRegistration> exportService(ServiceReference 
reference,
            Map<String, Object> properties);

The 'properties' argument is intended to be interpreted to override the 
properties on the service reference.

I realized that the ECF IHostContainerSelector should *also* allow the 
ServiceReference properties to be overridden...and so should almost 
certainly have a signature like this:

    IRemoteServiceContainer[] selectHostContainers(
            ServiceReference serviceReference, String[] exportedInterfaces,
            String[] exportedConfigs, String[] serviceIntents, 
Map<String, Object> overrideProperties);

This would allow the host container selector implementation to also use 
the overrideProperties in the selection/creation/configuration of a 
remote service host container.  This is not critical, but it is a 
desirable generalization and IMHO should be fixed.

So...the upshot is that I would like to add this overrideProperties 
argument to IHostContainerSelector API (and implementations, obviously) 
to ECF as soon as possible.

The IHostContainerSelector is API...albeit ECF-internal API ...as it 
allows people to easily customize ECF's RSA implementation.  It does not 
represent any change in the RSA-specified standard API.

My proposal is to introduce this API change right away, and release it 
in ECF 3.5.1.  I would like to seek a waiver to include in the 3.5.1 
maintenance release (with approximate release date of mid-May 2011).   I 
think it would be a bit much to go through a minor release review (i.e. 
3.6) for this ECF-internal API change.

Any opinions/views/comments?

Thanks,

Scott