> +
> +import com.google.common.base.Function;
> +import com.google.common.base.Supplier;
> +
> +/**
> + * @author Jeremy Daggett
> + */
> +@Singleton
> +public class RegionToCDNEndpoint implements Function<Object, URI> {
> +
> + private final Supplier<Map<String, Supplier<URI>>> endpointsSupplier;
> +
> + @Inject
> + public RegionToCDNEndpoint(@ApiVersion final String apiVersion, final
> RegionIdToURISupplier.Factory factory) {
> + this.endpointsSupplier =
> factory.createForApiTypeAndVersion(ServiceType.OBJECT_CDN, apiVersion);
> + }
@jdaggett yes, but you're missing one point. I'm not saying the CDN api is
obtained directly, but it is obtained based in _**two parameters**_:
* The region.
* The service type.
Depending on those two parameters, the CDN API might point to an endpoint or
another, right?
The first one is provided when calling:
```java
CDNApi cdnApi = api.cdnApiInRegion("DFW");
```
And the important thing here is: how can the user configure the service type?
Your current implementation **hardcodes** the service type, so users won't be
able to configure the one they want to use. Is that what we want?
If you remember the email in the mailing list, that's exactly what you were
asking for: how to avoid hardcoding that service type? My initial proposal was
to create a method that received both, the region and the service type, but in
the same conversation that approach was discarded, and we looked to an
alternative approach.
With the code change proposed here (to receive the service type from the
injector), users will be able to use the api like this:
```java
// If desired, users can manually set the service type to "object-cdn" or
"object-storage"
// to override the one defined in the metadata.defaultProperties() for the
provider.
Properties props = new Properties();
props.setProperty(KeystoneProperties.SERVICE_TYPE, OBJECT_CDN);
CloudFilesApi api = ContextBuilder.newBuilder("rackspace-cloudfiles")
.credentials(username, apiKey)
.overrides(props) // <-- This will populate the property to the Injector
.buildApi(CloudFilesApi.class);
// Now this call will generate the API pointing to the endpoint corresponding
to the service type
// configured when creating the context (or the defined in the provider
metadata if no properties
// were provided)
CDNApi cdnApi = api.cdnApiInRegion("DFW");
```
With my proposed code change, instead of always using the "object-cdn" service
type users will be able to specify, via properties when creating the context,
the service type they want to use. Supporting "object-storage" and "object-cdn"
was the initial requirement, and the current implementation **does not**
support both. The service type **must be parameterized** to accomplish that.
Is it more clear now?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/79/files#r10062881
