Re: ResourceProvider bubbling

[Robert Munteanu]

Hi Dominik,

On Tue, Nov 11, 2014 at 5:38 PM, Dominik Süß  wrote:
> Hi everyone,
>
> comming back to that case. As it turned out the resourceProvider was
> actually the only feasible solution since merging the valueMap was not
> sufficient but I found cases where I had to mount in substructures (via
> synthetic resources).
>
> Now I'm facing a follow up issue with CRUD support of this. Reading is no
> issue anymore but as soon as I write I would need to always delegate this
> to the lower ResourceProvider.

Can't you simply do that? At the point when you create your resource
from your own ResourceProvider you should know the ResourceProvider
you're wrapping ( probably a modifiable resource provider ) so you
could delegate it from your own RP.

Cheers,

Robert

>
> Due to [0] I face the first issue since my RP does return a Syntethic
> Resource in the original location because it yet doesn't exist - it then
> fails because the check here is not checking if the colliding resource is a
> synthetic resource provided by my resourceProvider.
>
> Additionally the PostServlet is not bubbling through the resourceproviders
> to try to execude the CUD operations but failing because my RP is not a
> modifiableResourceProvider. On the other hand when I implement the
> modifyingResourceProvider Interface I see no option to delegate the delete
> since the lookup for deleteexecution does not iterate over the RPs but
> seems just to return the first one.
>
> Any idea how I could solve those two issues?
>
> Best regards
> Dominik
>
> [0]
> https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/operations/AbstractCreateOperation.java#L638
> 
>
>
> On Tue, Nov 4, 2014 at 10:19 AM, Carsten Ziegeler 
> wrote:
>
>> Am 04.11.14 um 09:42 schrieb Dominik Süß:
>> > Hi Felix,
>> >
>> > if I got your right you propose to use a membervariable instead of a
>> > threadlocal since my ResourceProviderFactory (which I already use btw.)
>> > makes sure that I get the same ResourceProvider Instance handled by the
>> > same thread - and since it is the same instance there would be no need
>> for
>> > a thread local.
>> >
>> > Did I get this right? This would just be a minor change to the solution I
>> > already have (basically replacing the threadlocal by instance variable).
>> >
>> > Is there no other solution?
>> > Acutally the perfect thing would be to have a ResourceDecorator that is
>> > scoped to a specific path or in this case it could be even feasible to
>> base
>> > it on resourceType (kind of a reoccuring pattern for decorators,
>> > processors, filters etc.)
>> >
>>
>> You can do this, check the path/resource type in the decorator and only
>> decorate on a positive check
>>
>> There are no registration properties which do the work for you though,
>> but I don't think we need those.
>>
>> Carsten
>>
>>
>> > Best regards
>> > Dominik
>> >
>> > On Tue, Nov 4, 2014 at 7:07 AM, Felix Meschberger 
>> > wrote:
>> >
>> >> Hi
>> >>
>> >> One option would be if your ResourceProvider is provided by a
>> >> ResourceProviderFactory. In this case, each ResourceResolver gets its
>> >> distinct ResourceProvider instance. And since ResourceResolver are not
>> >> thread safe you can be reasonably sure, that a certain ResourceResolver
>> is
>> >> used in a single thread.
>> >>
>> >> So when your ResourceProvider is hit the first time you can set a flag
>> as
>> >> an instance field in the ResourceProvider which you can check on the
>> second
>> >> pass. Before returning from the first call, you clear the flag again.
>> >>
>> >> Something like this:
>> >>
>> >>ResourceResolver.getResource
>> >>   ResourceProviderX.getResource
>> >>   setFlag
>> >>  ResourceResolver.getResource
>> >>  ResourceProviderX.getResource
>> >>  return null since flag is set
>> >>  … other ResourceProviders …
>> >>   clearFlag
>> >>   some more work
>> >>
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >>
>> >>> Am 03.11.2014 um 15:05 schrieb Dominik Süß :
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> I just have a case where I have to split away some content from the
>> >>> original location and split parts in a dedicated subresource. I also
>> have
>> >>> the constraint that access must work exactly the same (so the
>> >> resourcetree
>> >>> should work like before while persistance splits the attributes up.
>> >>> This sounds like a case for ResourceDecorator but since this is just
>> for
>> >> a
>> >>> small content branch and ResourceDecorators are way to intrusive.
>> >>>
>> >>> The option I found was to hook in a ResourceProvider, set a threadlocal
>> >>> flag for "internal Resolution", perform another resolve for the same
>> >> path,
>> >>> return null for an internal resolve (therefore bubble to next
>> >>> Resou

Re: ResourceProvider bubbling

[Dominik Süß]

Hi everyone,

comming back to that case. As it turned out the resourceProvider was
actually the only feasible solution since merging the valueMap was not
sufficient but I found cases where I had to mount in substructures (via
synthetic resources).

Now I'm facing a follow up issue with CRUD support of this. Reading is no
issue anymore but as soon as I write I would need to always delegate this
to the lower ResourceProvider.

Due to [0] I face the first issue since my RP does return a Syntethic
Resource in the original location because it yet doesn't exist - it then
fails because the check here is not checking if the colliding resource is a
synthetic resource provided by my resourceProvider.

Additionally the PostServlet is not bubbling through the resourceproviders
to try to execude the CUD operations but failing because my RP is not a
modifiableResourceProvider. On the other hand when I implement the
modifyingResourceProvider Interface I see no option to delegate the delete
since the lookup for deleteexecution does not iterate over the RPs but
seems just to return the first one.

Any idea how I could solve those two issues?

Best regards
Dominik

[0]
https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/impl/operations/AbstractCreateOperation.java#L638



On Tue, Nov 4, 2014 at 10:19 AM, Carsten Ziegeler 
wrote:

> Am 04.11.14 um 09:42 schrieb Dominik Süß:
> > Hi Felix,
> >
> > if I got your right you propose to use a membervariable instead of a
> > threadlocal since my ResourceProviderFactory (which I already use btw.)
> > makes sure that I get the same ResourceProvider Instance handled by the
> > same thread - and since it is the same instance there would be no need
> for
> > a thread local.
> >
> > Did I get this right? This would just be a minor change to the solution I
> > already have (basically replacing the threadlocal by instance variable).
> >
> > Is there no other solution?
> > Acutally the perfect thing would be to have a ResourceDecorator that is
> > scoped to a specific path or in this case it could be even feasible to
> base
> > it on resourceType (kind of a reoccuring pattern for decorators,
> > processors, filters etc.)
> >
>
> You can do this, check the path/resource type in the decorator and only
> decorate on a positive check
>
> There are no registration properties which do the work for you though,
> but I don't think we need those.
>
> Carsten
>
>
> > Best regards
> > Dominik
> >
> > On Tue, Nov 4, 2014 at 7:07 AM, Felix Meschberger 
> > wrote:
> >
> >> Hi
> >>
> >> One option would be if your ResourceProvider is provided by a
> >> ResourceProviderFactory. In this case, each ResourceResolver gets its
> >> distinct ResourceProvider instance. And since ResourceResolver are not
> >> thread safe you can be reasonably sure, that a certain ResourceResolver
> is
> >> used in a single thread.
> >>
> >> So when your ResourceProvider is hit the first time you can set a flag
> as
> >> an instance field in the ResourceProvider which you can check on the
> second
> >> pass. Before returning from the first call, you clear the flag again.
> >>
> >> Something like this:
> >>
> >>ResourceResolver.getResource
> >>   ResourceProviderX.getResource
> >>   setFlag
> >>  ResourceResolver.getResource
> >>  ResourceProviderX.getResource
> >>  return null since flag is set
> >>  … other ResourceProviders …
> >>   clearFlag
> >>   some more work
> >>
> >>
> >> Regards
> >> Felix
> >>
> >>
> >>> Am 03.11.2014 um 15:05 schrieb Dominik Süß :
> >>>
> >>> Hi everyone,
> >>>
> >>> I just have a case where I have to split away some content from the
> >>> original location and split parts in a dedicated subresource. I also
> have
> >>> the constraint that access must work exactly the same (so the
> >> resourcetree
> >>> should work like before while persistance splits the attributes up.
> >>> This sounds like a case for ResourceDecorator but since this is just
> for
> >> a
> >>> small content branch and ResourceDecorators are way to intrusive.
> >>>
> >>> The option I found was to hook in a ResourceProvider, set a threadlocal
> >>> flag for "internal Resolution", perform another resolve for the same
> >> path,
> >>> return null for an internal resolve (therefore bubble to next
> >>> ResourceProvider) reset the threadlocal and wrap the returned resource.
> >>>
> >>> But, thread locals always feel a bit hacky and I wonder if there is
> >> another
> >>> option. I yet haven't seen a way to bubble through the
> resourceProviders
> >> or
> >>> directly address specific ResourceProviders.
> >>>
> >>> Any idea how I could improve for that scenario?
> >>>
> >>> Cheers
> >>> Dominik
> >>
> >>
> >
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...

Re: ResourceProvider bubbling

[Carsten Ziegeler]

Am 04.11.14 um 09:42 schrieb Dominik Süß:
> Hi Felix,
> 
> if I got your right you propose to use a membervariable instead of a
> threadlocal since my ResourceProviderFactory (which I already use btw.)
> makes sure that I get the same ResourceProvider Instance handled by the
> same thread - and since it is the same instance there would be no need for
> a thread local.
> 
> Did I get this right? This would just be a minor change to the solution I
> already have (basically replacing the threadlocal by instance variable).
> 
> Is there no other solution?
> Acutally the perfect thing would be to have a ResourceDecorator that is
> scoped to a specific path or in this case it could be even feasible to base
> it on resourceType (kind of a reoccuring pattern for decorators,
> processors, filters etc.)
> 

You can do this, check the path/resource type in the decorator and only
decorate on a positive check

There are no registration properties which do the work for you though,
but I don't think we need those.

Carsten


> Best regards
> Dominik
> 
> On Tue, Nov 4, 2014 at 7:07 AM, Felix Meschberger 
> wrote:
> 
>> Hi
>>
>> One option would be if your ResourceProvider is provided by a
>> ResourceProviderFactory. In this case, each ResourceResolver gets its
>> distinct ResourceProvider instance. And since ResourceResolver are not
>> thread safe you can be reasonably sure, that a certain ResourceResolver is
>> used in a single thread.
>>
>> So when your ResourceProvider is hit the first time you can set a flag as
>> an instance field in the ResourceProvider which you can check on the second
>> pass. Before returning from the first call, you clear the flag again.
>>
>> Something like this:
>>
>>ResourceResolver.getResource
>>   ResourceProviderX.getResource
>>   setFlag
>>  ResourceResolver.getResource
>>  ResourceProviderX.getResource
>>  return null since flag is set
>>  … other ResourceProviders …
>>   clearFlag
>>   some more work
>>
>>
>> Regards
>> Felix
>>
>>
>>> Am 03.11.2014 um 15:05 schrieb Dominik Süß :
>>>
>>> Hi everyone,
>>>
>>> I just have a case where I have to split away some content from the
>>> original location and split parts in a dedicated subresource. I also have
>>> the constraint that access must work exactly the same (so the
>> resourcetree
>>> should work like before while persistance splits the attributes up.
>>> This sounds like a case for ResourceDecorator but since this is just for
>> a
>>> small content branch and ResourceDecorators are way to intrusive.
>>>
>>> The option I found was to hook in a ResourceProvider, set a threadlocal
>>> flag for "internal Resolution", perform another resolve for the same
>> path,
>>> return null for an internal resolve (therefore bubble to next
>>> ResourceProvider) reset the threadlocal and wrap the returned resource.
>>>
>>> But, thread locals always feel a bit hacky and I wonder if there is
>> another
>>> option. I yet haven't seen a way to bubble through the resourceProviders
>> or
>>> directly address specific ResourceProviders.
>>>
>>> Any idea how I could improve for that scenario?
>>>
>>> Cheers
>>> Dominik
>>
>>
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: ResourceProvider bubbling

[Dominik Süß]

Hi Felix,

if I got your right you propose to use a membervariable instead of a
threadlocal since my ResourceProviderFactory (which I already use btw.)
makes sure that I get the same ResourceProvider Instance handled by the
same thread - and since it is the same instance there would be no need for
a thread local.

Did I get this right? This would just be a minor change to the solution I
already have (basically replacing the threadlocal by instance variable).

Is there no other solution?
Acutally the perfect thing would be to have a ResourceDecorator that is
scoped to a specific path or in this case it could be even feasible to base
it on resourceType (kind of a reoccuring pattern for decorators,
processors, filters etc.)

Best regards
Dominik

On Tue, Nov 4, 2014 at 7:07 AM, Felix Meschberger 
wrote:

> Hi
>
> One option would be if your ResourceProvider is provided by a
> ResourceProviderFactory. In this case, each ResourceResolver gets its
> distinct ResourceProvider instance. And since ResourceResolver are not
> thread safe you can be reasonably sure, that a certain ResourceResolver is
> used in a single thread.
>
> So when your ResourceProvider is hit the first time you can set a flag as
> an instance field in the ResourceProvider which you can check on the second
> pass. Before returning from the first call, you clear the flag again.
>
> Something like this:
>
>ResourceResolver.getResource
>   ResourceProviderX.getResource
>   setFlag
>  ResourceResolver.getResource
>  ResourceProviderX.getResource
>  return null since flag is set
>  … other ResourceProviders …
>   clearFlag
>   some more work
>
>
> Regards
> Felix
>
>
> > Am 03.11.2014 um 15:05 schrieb Dominik Süß :
> >
> > Hi everyone,
> >
> > I just have a case where I have to split away some content from the
> > original location and split parts in a dedicated subresource. I also have
> > the constraint that access must work exactly the same (so the
> resourcetree
> > should work like before while persistance splits the attributes up.
> > This sounds like a case for ResourceDecorator but since this is just for
> a
> > small content branch and ResourceDecorators are way to intrusive.
> >
> > The option I found was to hook in a ResourceProvider, set a threadlocal
> > flag for "internal Resolution", perform another resolve for the same
> path,
> > return null for an internal resolve (therefore bubble to next
> > ResourceProvider) reset the threadlocal and wrap the returned resource.
> >
> > But, thread locals always feel a bit hacky and I wonder if there is
> another
> > option. I yet haven't seen a way to bubble through the resourceProviders
> or
> > directly address specific ResourceProviders.
> >
> > Any idea how I could improve for that scenario?
> >
> > Cheers
> > Dominik
>
>

Re: ResourceProvider bubbling

[Felix Meschberger]

Hi

One option would be if your ResourceProvider is provided by a 
ResourceProviderFactory. In this case, each ResourceResolver gets its distinct 
ResourceProvider instance. And since ResourceResolver are not thread safe you 
can be reasonably sure, that a certain ResourceResolver is used in a single 
thread.

So when your ResourceProvider is hit the first time you can set a flag as an 
instance field in the ResourceProvider which you can check on the second pass. 
Before returning from the first call, you clear the flag again.

Something like this:

   ResourceResolver.getResource
  ResourceProviderX.getResource
  setFlag
 ResourceResolver.getResource
 ResourceProviderX.getResource
 return null since flag is set
 … other ResourceProviders …
  clearFlag
  some more work


Regards
Felix


> Am 03.11.2014 um 15:05 schrieb Dominik Süß :
> 
> Hi everyone,
> 
> I just have a case where I have to split away some content from the
> original location and split parts in a dedicated subresource. I also have
> the constraint that access must work exactly the same (so the resourcetree
> should work like before while persistance splits the attributes up.
> This sounds like a case for ResourceDecorator but since this is just for a
> small content branch and ResourceDecorators are way to intrusive.
> 
> The option I found was to hook in a ResourceProvider, set a threadlocal
> flag for "internal Resolution", perform another resolve for the same path,
> return null for an internal resolve (therefore bubble to next
> ResourceProvider) reset the threadlocal and wrap the returned resource.
> 
> But, thread locals always feel a bit hacky and I wonder if there is another
> option. I yet haven't seen a way to bubble through the resourceProviders or
> directly address specific ResourceProviders.
> 
> Any idea how I could improve for that scenario?
> 
> Cheers
> Dominik

ResourceProvider bubbling

[Dominik Süß]

Hi everyone,

I just have a case where I have to split away some content from the
original location and split parts in a dedicated subresource. I also have
the constraint that access must work exactly the same (so the resourcetree
should work like before while persistance splits the attributes up.
This sounds like a case for ResourceDecorator but since this is just for a
small content branch and ResourceDecorators are way to intrusive.

The option I found was to hook in a ResourceProvider, set a threadlocal
flag for "internal Resolution", perform another resolve for the same path,
return null for an internal resolve (therefore bubble to next
ResourceProvider) reset the threadlocal and wrap the returned resource.

But, thread locals always feel a bit hacky and I wonder if there is another
option. I yet haven't seen a way to bubble through the resourceProviders or
directly address specific ResourceProviders.

Any idea how I could improve for that scenario?

Cheers
Dominik