Hi Ian Would it make sense to remove the AdapterFactory implementation and instead pass along the URIProvider service(s) using the o.a.s.jcr.resource.internal.HelperData object instead? According to its javadoc, it is "used to pass several services/data to the resource".
I assume the AdapterFactory is used because you don't have access to the OSGi service registry in JcrNodeResource where you need the URIProvider. Regards Julian On Mon, Sep 18, 2017 at 1:12 PM, Ian Boston <ianbos...@gmail.com> wrote: > Hi, > Good catch, didn't implement the vital interface. > Put the API into o.a.s.api.resource (o.a.s.resource.api doesn't exist), and > added some doc. While writing that doc realised there was no way of getting > a URI for a private network context (if available) so added a method and > documented. > The component is lazy now. > Best Regards > Ian > > > On 18 September 2017 at 06:15, Carsten Ziegeler <cziege...@apache.org> > wrote: > >> Ian Boston wrote >> > Hi, >> > Here is an updated patch. >> > >> > https://github.com/apache/sling/compare/trunk...ieb:OAK- >> 6575-3-1?expand=1 >> > >> >> Thanks for updating the patch. >> >> I think we should move ExternalisableInputStream to o.a.s.resource.api, >> so other resource providers could potentially use it as well. >> >> I guess JcrExternalisableInputStream should implement that interface :) >> >> It's usually not necessary to use "immediate=true" on a component. It >> prevents lazy instantiation and should only be used if there is a good >> reason for it. >> >> Regards >> >> Carsten >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >>
