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 <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 <cziege...@apache.org> 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 <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 > >> > >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
