Hi, That would require javax.jcr.Binary to implement Adaptable, which it cant. (OakBinary could but it doesnt need to).
Using Sling AdapterFactory/AdapterManger javadoc (to be replaced with Oaks internal version of the same) What is needed is an AdapterFactory for javax.jcr.Binary to SignedBinary provided by the S3DataStore itself. Since javax.jcr.Binary cant extend Adaptable, its not possible to call binary.adaptTo(SignedBinary.class) without a cast, hence, the call is done via the AdapterManager[1] SignedBinary signedBinary = adapterManager.getAdapter(binary, SignedBinary.class); --- You could just jump to URI uri = adapterManager.getAdapter(binary, URI.class); No API changes to any existing Oak APIs, Best Regards Ian 1 https://sling.apache.org/apidocs/sling5/org/apache/sling/api/adapter/AdapterManager.html On 24 August 2017 at 12:38, Chetan Mehrotra <[email protected]> wrote: > > various layers involved. The bit I don't understand is how the adaptable > > pattern would make those go away. To me that pattern is just another way > to > > implement this but it would also need to deal with all those layers. > > Yes this adapter support would need to be implement at all layers. > > So call to > 1. binary.adaptTo(SignedBinary.class) //binary is JCR Binary > 2. results in blob.adaptTo(SignedBinary.class) //blob is Oak Blob. > Blob interface would extend adaptable > 3. results in SegmentBlob delegating to BlobStoreBlob which > 4. delegates to BlobStore // Here just passing the BlobId > 5. which delegates to DataStoreBlobStore > 6. which delegates to S3DataStore > 7. which returns the SignedBinary implementation > > However adapter support would allow us to make this instance of check > extensible. Otherwise we would be hardcoding instance of check to > SignedBinary at each of the above place though those layers need not > be aware of SignedBinary support (its specific to S3 impl) > > Chetan Mehrotra >
