> >> 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]
