fine - i've created https://issues.apache.org/jira/browse/SLING-6029 to track the changes
stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Thursday, September 1, 2016 3:10 PM >To: [email protected] >Subject: Re: [contextaware config] Default configuration and naming > >> >>> I think we should have /conf, /apps, /libs as the default configuration, >>> which means /conf is searched first, followed by /apps and followed by >>> /libs. >> >> currently we are using /config by default, but we could switch to /conf >as well, we just have to decide. > >Yes, I started with /config just to be able to run confmgr in parallel >for some time, but I think /conf would be better. > >> >>> For fallback, we could go with /conf/global, /apps/global, and >>> /libs/global. >> >> this is something like a double-defaulting - first fallback from /conf to >/apps and /libs, and then to ./global from the three. > >Right. > >> >> my idea was the defaulting is a bit more complex: >> >> consider having a content structure like this >> >> /content >> /tenant1 - context path /content/tenant1 >> /region1 - context path /content/tenant1/region1 >> /site1 - context path /content/tenant1/region1/site1 >> /page1 >> >> if you want to get configuration for page1, it may be searched in this >order in: >> /conf/tenant1/region1/site1 >> /conf/tenant1/region1 >> /conf/tenant1 >> /conf/global >> /apps/global >> /libs/global >> >> not sure about the paths in detail, but you get the concept of nested >context paths with allow to define configurations globally for a tenant, >region or for each site individually. > >Yes, I agree - actually my initial post was wrong or not complete. We >have one configuration which defines from which paths configurations are >allowed to be read. >This should be /conf, /apps/conf, and /libs/conf > >The fallbacks are /conf/default, /apps/conf and /libs/conf - so with >your example it would search at: > /conf/tenant1/region1/site1 > /conf/tenant1/region1 > /conf/tenant1 > /conf/global > /apps/conf > /libs/conf > >> >> >>> The property on a content resource containing the configuration path is >>> currently named "sling:config", but I think we should rather name it >>> "sling:configcontext" or "sling:config-context" as this is a little bit >>> more precise. >> >> in my idea having such a property is only one of the possibilities to >detect the configuration context paths (see SLING-6023 for details). >Sure. > >> it should not be named "configcontext" because it does not contain the >context path, but the config path. the context path is the content resource >path itself. >Yes, that's correct. > >> perhaps something like "sling:config-ref" or "sling:config-path"? >I like config-ref. > >> >> >>> Configurations are currently searched in a bucket called >>> "sling:configs", I'm not sure if this is the best name though. >> >> at least when thinking about classical configurations (like osgi configs) >this name sounds intuitive, although in case of the >ConfigurationResourceResolver we overload the meaning of configuration with >all sorts of configurable stuff. an alternative could be "sling:config- >params" or "sling:config-parameters". > >Ok, let's stick with sling:configs for now. > >Thanks >Carsten > > > > >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
