> No API changes to any existing Oak APIs,
Some API needs to be exposed. Note again Oak does not depend on Sling
API. Any such integration code is implemented in Sling Base module
[1]. But that module would still require some API in Oak to provide
such an adaptor
The adaptor proposal here is for enabling layers within Oak to allow
conversion of JCR Binary instance to SignedBinary. Now how this is
exposed to end user depends on usage context
Outside Sling
------------------
Check if binary instanceof Oak Adaptable. If yes then cast it and adapt it
import org.apache.jackrabbit.oak.api.Adaptable
Binary b = ...
SignedBinary sb = null
if (b instanceof Adaptable) {
sb = ((Adaptable)b).adaptTo(SignedBinary.class);
}
Within Sling
----------------
Have an AdapterManager implemented in Sling JCR Base [1] which uses
above approach
Chetan Mehrotra
[1] https://github.com/apache/sling/tree/trunk/bundles/jcr/base
On Thu, Aug 24, 2017 at 4:55 AM, Ian Boston <i...@tfd.co.uk> wrote:
> From the javadoc in [1]
>
> "The adaptable object may be any non-null object and is not required to
> implement the Adaptable interface."
>
>
> On 24 August 2017 at 12:54, Ian Boston <i...@tfd.co.uk> wrote:
>
>> 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 <chetan.mehro...@gmail.com>
>> 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
>>>
>>
>>
