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 <fmesc...@adobe.com> 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üß <dominik.su...@gmail.com>: > > > > 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 > >
