Hi Dominik, On Tue, Nov 11, 2014 at 5:38 PM, Dominik Süß <dominik.su...@gmail.com> 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 > <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 >>
