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üß <[email protected]>:
>
> 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
