> 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
