Thanks Andrew, it now makes sense that ACLs would be a provider-specific feature. Maybe my confusion arose simply because the S3-specific docs [1] were a bit out-of-date, with regards to getting the provider-specific API? (referencing a method which no longer exists)
AFA supporting ACLs on the AWSS3PutOptions, I'm afraid that adding this to the latest version of jclouds wouldn't help me at all. I'm stuck on 1.6.3 because of a Guava incompatibility between Jclouds (see JCLOUDS-427) and the version of HBase we're using (see HBASE-9667). But that's fine; instead of passing around a BlobStoreContext in my code, it's a straightforward change to use an S3Client object instead, which gives me access to all the S3-specific features (like ACLs) that I need. [1] http://jclouds.apache.org/guides/aws/ *Steve Kingsland* Senior Software Engineer *Opower* <http://www.opower.com/> *We’re hiring! See jobs here <http://www.opower.com/careers>* On Wed, Sep 24, 2014 at 1:10 PM, Andrew Phillips <andr...@apache.org> wrote: > was apparently removed in Jclouds 1.6. I think I can work around this using >> contextBuilder.buildApi(S3Client.class) and the S3Object class to set the >> ACL. >> >> But then if I have to use an S3-specific API to set an ACL, why not just >> use the com.amazonaws.services.s3.AmazonS3Client client directly? How is >> Jclouds actually benefitting me, if I'm using it to code directly to the >> S3 >> provider? >> > > The challenge here is that ACLs are not something that is supported by all > the blobstores jclouds supports, so is not included in the BlobStore > abstraction. In other words, coding with ACLs on blobs is implicitly making > your code provider-dependent already. > > In order to support provider-specific features like that, jclouds indeed > supports access to the underlying API, as you describe (see [1] for more > details). This is indeed not all that different from using the provider > client directly, but if the number of provider-specific calls you need to > make are small, using jclouds will allow you to move to another provider > relatively easily if you can re-implement the provider-specific calls or > remove them. > > A "middle-ground approach" that jclouds takes for some options is the > ability to pass provider-specific options to the abstract interface. E.g. > something like: > > Blob myBlob = ... > PutOptions options = AWSS3PutOptions.Builder. > storageClass(...).otherOption...; > blobstore.putBlob("myContainer", myBlob, options); // [2] > > This is *also* AWS-specific code, but not quite as tied to the specific > underlying API. Unfortunately, "withAcl" is not an option currently > supported on AWSS3PutOptions [3] (it *is* supported on PutObjectOptions > [4], but that's the options class for the S3-specific call). > > That should be a relatively easy fix, though - would you be interested in > submitting a PR for that? > > Hope that helps! > > ap > > [1] http://jclouds.apache.org/start/concepts/ > [2] http://javadocs.jclouds.cloudbees.net/org/jclouds/ > blobstore/BlobStore.html#putBlob(java.lang.String, > org.jclouds.blobstore.domain.Blob, org.jclouds.blobstore.options. > PutOptions) > [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/aws/ > s3/blobstore/options/AWSS3PutOptions.html > [4] http://javadocs.jclouds.cloudbees.net/org/jclouds/s3/ > options/PutObjectOptions.html >
