>A non-expert question here, but do we need access to both? Would e.g. ChefApi
>not be enough?
The point here is that jclouds-karaf uses the created jclouds Context name and
id to index and build the cache of services. You can create several
ComputeService instances, with different credentials/providers, and work with
all them at the same time, and karaf indexes them using the Context information.
In Compute and BlobStore, the created Context is the ComputeServiceContext and
the BlobStoreContext (which also implement View but that's not relevant here),
which produce the corresponding ComputeService and BlobStore objects that are
used by jclouds-karaf. Those objects have a "getContext()" method, providing
access to the context that created them, and that method is used to get the
name of the context when it comes to cache and index the Service objects. It
basically caches something like:
ctx-name1 -> ComputeService1
ctx-name2 -> ComputeService2
ctx-name3 -> BlobStore1
ctx-name4 -> ChefService1
The commit that broke karaf removed the ChefContext, because it made no sense:
Chef does not have an abstraction view (although it is tightly integrated with
the Compute one), and it didn't make sense to have a specific Context
implementation for chef that provided nothing, so I removed it. In the absence
of a view or specific context implementation, jclouds creates an
ApiContext<ApiClass> context, providing access to the api.
What I didn't want to do, is to expose a getter to that ApiContext in the
ChefApi or the ChefService. There is nothing special about that generic context
(as opposed to the Compute and BlobStore context), so it does not make sense to
expose it. This is what motivated this change: since there is no access to the
"creator context" from the ChefService or the ChefApi, I changed the entity
that gets cached and indexed by jclouds-karaf in the case of Chef. Instead of
indexing the ChefService, I index directly the Context. Being the "context" the
entity jclouds-karaf works with, makes it unnecessary to provide a "getContext"
method in the ChefApi or ChefService, so I preferred this approach to avoid
coupling the Chef apis to the jclouds-karaf design. With this change, the karaf
service cache are now:
ctx-name1 -> ComputeService1
ctx-name2 -> ComputeService2
ctx-name3 -> BlobStore1
ctx-name4 -> ApiContext<ChefApi> (which can be used to get the
ChefService)
I'm not good at explaining things, but I hope the motivation is a bit more
clear now :)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/65#issuecomment-99024165
