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 <[email protected]> > 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üß <[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 >> >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
