Enhancement : To be able to dynamically build a finder even if it is not part of the StaticDataSource collection

[koushikr]

• Get or Create on finder creation for when a StaticDataSource is used as ServiceDataSource.

For someone using the ServiceFinderHub with a StaticDataSource, with a pre-defined set of services they intend to refresh rather than the whole world, if they want to fetch any finder dynamically which was not in the pre-defined set. For example, end users may use a protocol for ranger like http, ranger:///path - they will need a way to dynamically build the finder for it and get the respective nodes.

There are two options to do so, in the hub's finder, instead of the finder.get we can do,

 public Optional<ServiceFinder<T, R>> finder(final Service service) {
        val serviceFinder = finders.get().get(service);
        if(null == serviceFinder){
            try{
                val appended = serviceDataSource.tryAndAppend(service);
                if(appended){
                    updateAvailable();
                    awaitServiceFinderReadiness(service);
                }
            }catch (IllegalAccessException e){
                log.error("An illegal operation was attempted on the datasource to add the service {}", service);
            }
        }
        return Optional.ofNullable(finders.get().get(service));
    }

appended because want to give control to the client during declaration if the service should be appended or not, with a default of false, which will guard against client's mistakes of creating random finders

This makes the first call a little bit heavy but helps simplify the interface to the client.

Or we provide an end to end buildFinder abstraction till the RangerClient, and leave it to the clients to build the dynamic finders if they have to. We'll however make them part of our next refresh cycle anyway, but this leaks the abstractions outside and makes every client go down the same way.

Intend to do the former, @santanusinha thoughts?

We can club this with https://github.com/appform-io/ranger/issues/9

[koushikr]

Closing this.

Thinking long and hard about it. This comes at the cost of predictability and a sub routine which is not visible to the client, which may actually cause more harm than good. Clients will have to define their services before hand in the hub if they have to use it. Also reverted it in the PR.

[koushikr]

This is now addressed, here. Use it with care.