@jdaggett I completely understand that having to create two contexts is not ideal. Let's put things in order, so we can pick the right approach:

The requirement is to support "object-storage" and "rax:object-cdn" (and no other service types). In order to support both, you have to let the users choose the service type they want to use somehow. I can only think about three ways to do this:

* Allowing to dynamically specify it at runtime. To do this, the factory method should be modified [as I explained in the original email](http://markmail.org/message/d6knfqeyoslmuyk6). It would look like this:

```java
CDNApi api = cloudFilesApi.cdnApiInRegionAndServiceType(region, serviceType);
```

* If configuration has to be dynamic, but can't be a parameter, then it must be done "somewhere" in the execution environment (that is, the context). This is the approach discussed in this PR.
* If you don't want to pass the service type parameter dynamically and also don't want to configure it in the context, you could have two factory methods, one for each service type:

```java
CDNApi api = cloudFilesApi.cdnApiInRegionForObjectStorage(region);
CDNApi api = cloudFilesApi.cdnApiInRegionForRaxCDN(region);
```

In approach 1 and 2, a validation could be performed and failure would happen at runtime (which is not ideal), and in the third approach, you have one method for each service type, which seems confusing. All three approaches have pros and cons, but all three **meet the requirements**. Personally, I'd go for approach 1, and pass the service type tot he factory method, as I suggested in the initial email.

I think we shouldn't hardcode it, as it **would not meet the requirements to support both**. IMHO it is worse to leave the PR as-is, leaving users without the possibility to use "object-storage", than implementing one of the three suggested approaches.

Furthermore, if we merge this as-is, how long will it take until we support the "object-storage" service type? Can we put a date on that?

IMHO if we know, right now, that the PR does not meet the requirements, and already know three approaches that could fix that (with their pros and cons), we should go for one of them now, otherwise we are just introducing more (unnecessary) technical debt to the project.