ok, understood. i'm wondering if we should introduce an explicit parameter into the ConfigurationResourceResolver#getResource* methods to make it explicit that each "high-level" configuration-whatever resolver should define it's own "bucket" parent node, and not use the returned resource directly which may mess up with the other high-level resolvers when conflicts with child nodes occur.
stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Thursday, September 1, 2016 12:10 PM >To: dev@sling.apache.org >Subject: Re: [context-aware config] why sling:configs node > >> i've a question about ConfigurationBuilderImpl: why have we currently >introduced an implicit "sling:configs" parent node, which is automatically >added to the path when resolving a configuration. >> >> example: >> >> /content/site1[@sling:config=/config/site1] >> >> when i get the configuration named "x" for /content/site1 i get the >config from the resource /config/site1/sling:configs/x - instead of >/config/site1/x >> >> and why is this only done for the ConfigurationResolver, and not for the >ConfigurationResourceResolver? >> > >That's definitely one of the things to discuss :) >Now, the CRR has no knowledge about what it is looking for, so there is >no additional handling there. But this mechanism can be used to store >anything, not just configurations (in the sense that you use them with >the CR) but also other things like workflow models, client libraries and >whatnot (don't quote me on the examples, just to give an idea that this >is a broad approach). Putting all of these totally different things in >one bucket, didn't look like a good idea to me. >So I thought that every bucket (configurations, workflow models etc.) >uses its own parent node. For the configurations this would be >sling:configs. > >Regards > >Carsten > >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org >
