RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello oliver. >what's the status here? Will you move this project to Sling? this is not decided yet, no precise plans yet. this depends if it is useful for a broader audience in the sling community and projects/applications built with sling. until then just try it out from wcm.io. additionally i wanted to experiment with carstens idea to define configuration parameters using annotation classes as defined in the new OSGi specifications, but i had found no time for this yet. we already use this in production, but surely there is still room for improvement. >Is it possible to read/write configurations of the current resource only or >are configurations always collected up the tree? this depends on the "configuration finder strategey" used. our intention is that the configuration is normally not in the current resource, but always somewhere up in the tree. or in a shadow tree like /conf. see [1] and [2] for details. stefan [1] http://wcm.io/config/api/terminology.html [2] http://wcm.io/config/api/usage-spi.html
Re: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
On Saturday 04 October 2014 01:53:38 Stefan Seifert wrote: hi Stefan, > this proposal is about context-specific configuration, that means > configuration that cannot be stored as OSGi configurations. OSGi > configurations are always system-wide, so they are not well-suited for > storing configurations per context e.g. site, region or tenant. this is > related to the multitenancy discussion on this list, see [1] for a summary > of the past discussion. > > we've implementation a solution for this and are currently thinking about > donating it to Apache Sling. a documentation of what is currently > implemented is at [2]. the most relevant pages you should read are [3], > [4], [5], [6]. the implementation is based on the requirements from [7], > although not all that is listed on that page is implemented currently (but > a good deal of it). source code is at [8], a sample application at [9]. > > the current implementation is targeted to a specific sling-based CMS - but > besides the configuration editor and the parameter persistence provider it > does not depend on the CMS API but only on the Sling APIs, being > technically suited to be donated to Apache Sling. it's already published > under apache license 2.0. > > i'm interested if there is more need in the community for solving the > requirements i've listed, and the solutions we have implemented for it. and > if there are other sling committers who want to take part in its > development and enhancement as well. although we're using the current > implementation from wcm.io already in our projects nothing of it's current > architecture is carved in stone and i'm open to broaden the scope of > requirements it should support. > > WDYT? what's the status here? Will you move this project to Sling? Is it possible to read/write configurations of the current resource only or are configurations always collected up the tree? Thanks, O. > stefan > > > [1] https://cwiki.apache.org/confluence/x/zJBcAg > [2] http://wcm.io/config/ > [3] http://wcm.io/config/api/terminology.html > [4] http://wcm.io/config/api/usage-api.html > [5] http://wcm.io/config/api/usage-spi.html > [6] http://wcm.io/config/editor/usage.html > [7] https://wcm-io.atlassian.net/wiki/x/HIAH > [8] https://github.com/wcm-io/wcm-io/tree/master/config > [9] http://wcm.io/samples/config-sample-app/
RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello carsten. >So I think adding an adaptTo method to Configuration might do the trick: > >MyTypedConfig = >resource.adaptTo(Configuration.class).adaptTo(MyTypedConfig.class); > >The adaption within the implementation of the configuration class can be >done on the fly by creating a proxy. >We should check if >esource.adaptTo(Configuration.class).adaptTo(MyTypedConfig[].class) >would be implementable as well. this is nice as well. in this case the Configuration interface could be reduced to an extension of two other interfaces: ValueMap and Adaptable. what is left to be defined is how the string-based access without annotation types is working then in single and multiple variant. it's not a s easy as in DS, because in DS the context is always a service with a flat property list. here we have an aggregated view of a big number of annotation types which may overlap in the defined property names. stefan
Re: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Am 17.10.14 um 12:26 schrieb Stefan Seifert: > >> But what is the preferred way to get a configuration? I would assume >> that you get a configuration for a key similar to the pid for OSGi >> configurations. From an API point of view a >> >> T[] getConfiguration(String key, Class type); >> >> for a single and >> >> T[] getConfigurations(String key, Class type); >> >> for multiple would do? > > > proposal how the API can be used: > > --- > Configuration config = resource.adaptTo(Configuration.class); > > // single access > String value = config.get(MyTypedConfig.class).getParam1(); > > // multiple acces > MyTypedConfig[] myconfigs = config.getMultiple(MyTypedConfig.class); > String value = myconfigs[0].getParam1() > --- > > i thought about if we can get rid of the Configuration.class at all and > directly use MyTypedConfig.class or MyTypedConfig[].class in the adaptTo() > call, but i'm not sure if that’s working with annotation types. or use > Configuration.class only in cases where you need string-based value map > access. > > i currently do not see a need for a "key" when accessing the typed > configuration. > Right, the resource path is the key - I'm fine with that. I guess we need the Configuration for all use case where people don't want to define their configuration type. Directly adapting to MyTypedConfig or MyTypedConfig[] class is nice, but requires that you register each and every configuration type through an adapter factory. And if you want to use a different one, this gets difficult. So I think adding an adaptTo method to Configuration might do the trick: MyTypedConfig = resource.adaptTo(Configuration.class).adaptTo(MyTypedConfig.class); The adaption within the implementation of the configuration class can be done on the fly by creating a proxy. We should check if esource.adaptTo(Configuration.class).adaptTo(MyTypedConfig[].class) would be implementable as well. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
>But what is the preferred way to get a configuration? I would assume >that you get a configuration for a key similar to the pid for OSGi >configurations. From an API point of view a > >T[] getConfiguration(String key, Class type); > >for a single and > >T[] getConfigurations(String key, Class type); > >for multiple would do? proposal how the API can be used: --- Configuration config = resource.adaptTo(Configuration.class); // single access String value = config.get(MyTypedConfig.class).getParam1(); // multiple acces MyTypedConfig[] myconfigs = config.getMultiple(MyTypedConfig.class); String value = myconfigs[0].getParam1() --- i thought about if we can get rid of the Configuration.class at all and directly use MyTypedConfig.class or MyTypedConfig[].class in the adaptTo() call, but i'm not sure if that’s working with annotation types. or use Configuration.class only in cases where you need string-based value map access. i currently do not see a need for a "key" when accessing the typed configuration. stefan
Re: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Am 17.10.14 um 12:02 schrieb Stefan Seifert: > >>> 2) I'm assuming that the lookup key for these configuration objects is >>> the class name. IMHO, we need some kind of differentiator, see for >>> example my OAuth example earlier in this thread. >>> >> I haven't thought of this part yet, I've just stated my strong wish >> for strongly typed configuration objects :) > > it seems as we would need some sort of factory-configuration for this usecase > as well? this would be problematic in my initial approach with only a flat > list of properties in a valuemap as well. > > an oauth bundle would provide an annotation type class and mark it as > "multiple" or "factory". the API has to provide a way to get lists of > annotation class instances to iterate over. the configuration editor has to > support it as well. should be possible, although it would make the API a bit > more complex. > I'm just thinking out loud, especially as I don't have that much experience in this area. But what is the preferred way to get a configuration? I would assume that you get a configuration for a key similar to the pid for OSGi configurations. From an API point of view a T[] getConfiguration(String key, Class type); for a single and T[] getConfigurations(String key, Class type); for multiple would do? Again, just talking out loud without thinking of anything else related to this stuff. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
>> 2) I'm assuming that the lookup key for these configuration objects is >> the class name. IMHO, we need some kind of differentiator, see for >> example my OAuth example earlier in this thread. >> >I haven't thought of this part yet, I've just stated my strong wish >for strongly typed configuration objects :) it seems as we would need some sort of factory-configuration for this usecase as well? this would be problematic in my initial approach with only a flat list of properties in a valuemap as well. an oauth bundle would provide an annotation type class and mark it as "multiple" or "factory". the API has to provide a way to get lists of annotation class instances to iterate over. the configuration editor has to support it as well. should be possible, although it would make the API a bit more complex. stefan
RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello alex. >-Original Message- >From: Alexander Klimetschek [mailto:aklim...@adobe.com] >Sent: Tuesday, October 14, 2014 10:13 PM >To: dev@sling.apache.org >Subject: Re: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >I see 3 problems: > >- allowing to hook in a custom lookup strategy and not defining a clear lookup >& content model (too much magic in such things is bad, it should be obvious by >just browsing the JCR, just as with resource types) >- the idea of putting configurations itself under /content; configs have a >different management lifecycle and ACLs to shorten a discussion i've written a persistence provider that stores exactly you want it - in a shadow structure below /conf. this was only a small deviation from the existing persistence provider, documentation of "ConfStructurePersistenceProvider" at [1], impl at [2] still i see a need for a pluggable architecture at this point. starting on the green you are right. but we have already thousands of sling-based applications out there. and because no standard for context-specific configs existed in the past, every dev team has invented their own strategy having tens of thousands of sites with existing configuration. supporting them only needs an implementation of a custom PeristenceProvider, new configuration can be stored at /conf (the implementation supports multiple persistence providers for reading). and not all configuration parameters are so sensitive that they cannot be stored together with content. we have configuration parameters like "list of news category names" or parameters to tweak the style or behavior of some marketing features on the site. they should be allowed to be configured by authors and are more or less part of the content. but let's not start philosophical discussions on that. >- complexity of the API, Parameter<> generics just replicate the valuemap, but >in what seems to me like an overengineered fashion & one that shields too much >from the power of JCR, which might lead to have people invent custom string >formats instead of using JCR properties; in reality, 80% of properties are >strings, 10% each are boolean or integers (subjective experience stats TM :)) the Parameter<> generics only supports types supported by JCR (single and multi-valued), and a map which is stored in a string array internally. see more on this topic in my answer to justins mail. [1] http://wcm.io/config/core/persistence-providers.html [2] https://github.com/wcm-io/wcm-io/blob/master/config/core/src/main/java/io/wcm/config/core/persistence/impl/ConfStructurePersistenceProvider.java
Re: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
I see 3 problems: - allowing to hook in a custom lookup strategy and not defining a clear lookup & content model (too much magic in such things is bad, it should be obvious by just browsing the JCR, just as with resource types) - the idea of putting configurations itself under /content; configs have a different management lifecycle and ACLs - complexity of the API, Parameter<> generics just replicate the valuemap, but in what seems to me like an overengineered fashion & one that shields too much from the power of JCR, which might lead to have people invent custom string formats instead of using JCR properties; in reality, 80% of properties are strings, 10% each are boolean or integers (subjective experience stats TM :)) Cheers, Alex On 03.10.2014, at 16:53, Stefan Seifert wrote: > this proposal is about context-specific configuration, that means > configuration that cannot be stored as OSGi configurations. OSGi > configurations are always system-wide, so they are not well-suited for > storing configurations per context e.g. site, region or tenant. this is > related to the multitenancy discussion on this list, see [1] for a summary of > the past discussion. > > we've implementation a solution for this and are currently thinking about > donating it to Apache Sling. a documentation of what is currently implemented > is at [2]. the most relevant pages you should read are [3], [4], [5], [6]. > the implementation is based on the requirements from [7], although not all > that is listed on that page is implemented currently (but a good deal of it). > source code is at [8], a sample application at [9]. > > the current implementation is targeted to a specific sling-based CMS - but > besides the configuration editor and the parameter persistence provider it > does not depend on the CMS API but only on the Sling APIs, being technically > suited to be donated to Apache Sling. it's already published under apache > license 2.0. > > i'm interested if there is more need in the community for solving the > requirements i've listed, and the solutions we have implemented for it. and > if there are other sling committers who want to take part in its development > and enhancement as well. although we're using the current implementation from > wcm.io already in our projects nothing of it's current architecture is carved > in stone and i'm open to broaden the scope of requirements it should support. > > WDYT? > > stefan > > > [1] https://cwiki.apache.org/confluence/x/zJBcAg > [2] http://wcm.io/config/ > [3] http://wcm.io/config/api/terminology.html > [4] http://wcm.io/config/api/usage-api.html > [5] http://wcm.io/config/api/usage-spi.html > [6] http://wcm.io/config/editor/usage.html > [7] https://wcm-io.atlassian.net/wiki/x/HIAH > [8] https://github.com/wcm-io/wcm-io/tree/master/config > [9] http://wcm.io/samples/config-sample-app/ >
