Hi Dominik,
On Tue, Nov 11, 2014 at 5:38 PM, Dominik Süß 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 (vi
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
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 sin
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
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 sing
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.
