The point is that in order to support N "named services", karaf stores and indexes them by name. This way users can reference them by name and use each service easily.
That name is extracted from the cached object itself in several places along the karaf code. In the case of the ComputeService and BlobStore cases, both have a getContext() method that provides access to the (named) context and its name, so everything works out of the box. jclouds-karaf was build assuming that the services provide access to their creating context, but that was (perhaps) a poor decision based on the fact that all services actually had a specific context. That is no longer true in Chef. In the case of Chef, neither the ChefApi nor the ChefService provide access to the context and have no notion of a "name". In order to cache only the ChefApi we should introduce a wrapper object that adds a name to it (but that is very similar to directly caching the ApiContext itself), or modify the ChefApi or ChefService in a way that they can provide a name (for example by providing access to the creating context). I would like to avoid doing this too, because it is just coupling the ChefApi and ChefService to a specific design of jclouds-karaf, and that does not look like a good idea. The key point here is that the services jclouds-karaf provides, have to be "named". And the ChefApi and ChefService alone don't have a name. The context has, so given that they don't provide a direct access to the context, caching the context directly seems the better way to go. WDYT? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/65#issuecomment-99202413
