That does help, thanks Ignasi! In my case, I need to connect to an S3-compliant object store that my company is hosting internally. Right now it's Ceph, but they want me to interact with it using the S3 APIs, so the specific server becomes an implementation detail. The server might change, but it's unlikely that the API would (e.g. switching from S3 to the Swift API).
Given that, and that I need to use the Jclouds S3 API directly to set ACLs (and to check if a Blob exists), I'm trying to decide between using Jclouds' S3 provider API, or using the Amazon S3 client directly. In both cases I have working code which lets me do what I need to do. Right now my needs are fairly simple, but I can't help wondering if I'd be better served using the "official" S3 Java client that Amazon provides. Several other projects at my company are already using S3 hosted on AWS, so if I'm going to diverge from the Amazon client for accessing our internal S3, I need to have a good reason. And having portable abstractions, consistent API patterns, and clean dependencies doesn't really matter if I'm only ever going to use the S3 API for communicating with an (internally or externally hosted) object store. As far as the other "jclouds built-in HTTP features" you speak of, is there a features matrix somewhere for me to compare these benefits to what the amazon S3 client provides (that jclouds doesn't)? *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 11:42 AM, Ignasi Barrera <[email protected]> wrote: > It always depends on your needs. > > jclouds provides a portable abstraction layer that allows you to talk > to different clouds with the same code. It provides portable Compute, > Blobstore and Load Balancing models and APIs you can use. > > Each cloud, however, has its own semantics and specific features, and > although jclouds does a good job in putting them together behind the > portable abstractions, some provider specific things have to be done > with the provider specific APIs. IT wouldn't make sense to promote > every specific feature of every provider to the portable layer. > > That said, jclouds gives you the freedom to use the portable > abstractions or the provider specific APIs. Is up to you. But even > when you use the provider specific APIs to do concrete things, jclouds > provides menu benefits: > > * You still have a consistent pattern to use APIs. All apis are > constructed the same way and used in a similar fashion. You don't need > to learn how a new library works if you want to use the specific API > of several providers. > * You keep your dependencies clean, as provider specific APIs don't > bring new players. > * You also benefit from the jclouds built-in HTTP features: smart > retry policies, consistent error handling (guess how different APIs > can populate similar errors? jclouds does a good job standardizing > these behaviors), transparent pagination (you don't have to worry > about getting the N page or even if the list is paginated, jclouds > does it for you transparently), and more. > * It deals with authentication, sessions, expired tokens, etc. > > > In the end it is up to your use case. If you only need to talk with > one cloud provider and there exist a library for it, perhaps it is > better to just use that library, but jclouds is more than an "api > aggregator" and does a great job also when using the provider specific > APIs. > > HTH! > > I. > > On 24 September 2014 17:00, Steve Kingsland <[email protected]> > wrote: > > I'm trying to get code working which sets an ACL on an object when I > upload > > it to the BlobStore. I'm using the Jclouds S3 provider, and the closest > > documentation I can find is from the "Using S3" example code at > > http://jclouds.apache.org/guides/aws/: > > > > // when you need access to s3-specific features, > > // use the provider-specific context > > AWSS3Client s3Client = > > > AWSS3Client.class.cast(context.getProviderSpecificContext().getApi()); > > > > // make the object world readable > > String publicReadWriteObjectKey = "public-read-write-acl"; > > S3Object object = s3Client.newS3Object(); > > > > object.getMetadata().setKey(publicReadWriteObjectKey); > > object.setPayload("hello world"); > > s3Client.putObject(bucket, object, > withAcl(CannedAccessPolicy.PUBLIC_READ)); > > > > context.close(); > > > > Problem is, the getProviderSpecificContext() method 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? > > > > > > Steve Kingsland > > > > > > Senior Software Engineer > > > > Opower > > > > > > We’re hiring! See jobs here >
