Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi everyone, just added my comment to the mentioned usecase page at [0]. Please note that the solutions I've extracted that from were partially ui driven so I had to abstract quite a lot to get generic requirements out of those. This also means that it might still be a bit ui oriented which I would really try to avoid and focus on the reading part first. Anyways the editing process from a pure data (not ui) perspective might create some constraints that need to be thought of for the final api. Best regards Dominik [0] https://cwiki.apache.org/confluence/display/SLING/Context-specific+configuration+use+cases?focusedCommentId=47384290#comment-47384290 On Fri, Oct 17, 2014 at 2:31 PM, Bertrand Delacretaz wrote: > Hi Stefan, > > On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert > wrote: > > ...the alternative storing at /conf is already implemented [1] - it's up > to > > the system configuration which persistence provider is used... > > Ok, now I remember reading this earlier in this thread. Sorry about > the noise, it's a long thread ;-) > > -Bertrand >
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Stefan, On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert wrote: > ...the alternative storing at /conf is already implemented [1] - it's up to > the system configuration which persistence provider is used... Ok, now I remember reading this earlier in this thread. Sorry about the noise, it's a long thread ;-) -Bertrand
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello Bertrand. >On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert >wrote: >> ... https://cwiki.apache.org/confluence/x/1ATTAg ... > >Thanks for this. Looking at your use-cases it feels like your context >is always derived from the current resource's position in the content >tree, am I correct? yes, this is the configuration scope identified by a configuration id (e.g. the path of the site's root page) >If yes that explains why you suggest putting the configuration >alongside the content - but we might want to also support configs >stored under /conf or somewhere else safe. Quoting Alex K earlier in >this thread > >>> ...configs have a different management lifecycle and ACLs than content ... this is not directly related - storing the config along with the config was just the first persistence provider implemented as example. the configuration id the resource path, but as long if this key is preserved the configuration can be stored anywhere, also below a /conf node. the alternative storing at /conf is already implemented [1] - it's up to the system configuration which persistence provider is used. stefan [1] http://wcm.io/config/core/persistence-providers.html
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Stefan, On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert wrote: > ... https://cwiki.apache.org/confluence/x/1ATTAg ... Thanks for this. Looking at your use-cases it feels like your context is always derived from the current resource's position in the content tree, am I correct? If yes that explains why you suggest putting the configuration alongside the content - but we might want to also support configs stored under /conf or somewhere else safe. Quoting Alex K earlier in this thread >> ...configs have a different management lifecycle and ACLs than content ... which can be true but not in your use cases, IIUC - so both options probably make sense. -Bertrand
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
good idea, i've created a wiki page to collect usecases for "context-specific configuration" and added some we had in our projects in the past: https://cwiki.apache.org/confluence/x/1ATTAg feel free to add your use cases as well to that page. stefan >-Original Message- >From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] >Sent: Wednesday, October 15, 2014 4:01 PM >To: dev >Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert >wrote: >> ...this does not match the experience of our projects. we need those >parameters only in rare occasions directly >> in the scripts (e.g. sightly)... > >As usual, IMO having a shared list of use cases (wiki?) would help a >lot in getting consensus on what's needed and how to get there. ATM it >looks like there are quite different visions of this stuff. > >-Bertrand
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Am 15.10.14 um 15:40 schrieb Justin Edelson:
> Hi Carsten,
> I have two concerns with this model:
> 1) Creating an annotation class can be a bit heavyweight. If I want to
> just store a common value used across multiple scripts, doing so would
> require creating this class, compiling it, deploying the bundle, etc.
> vs. just adding a node property and referencing the property name from
> my scripts (the constant is a nice-to-have, but not strictly
> necessary). This is a non-issue for DS because the configuration
> annotation is tightly coupled with the configured component. But to my
> mind, one of the key targets for this new configuration structure is
> scripts.
The use cases I know and have heard of are not script related, the
configurations are evaluated on java code, so I have a bundle already
and creating the annotation then is easy. But I see your point and I see
no reason why we shouldn't support the direct access of properties but
recommend to use properly typed objects.
> 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 :)
> I'm also a bit concerned about the use of annotations in this way
> because they can't be extended (at least I think this is true). I'm
> not sure if this is a solved issue for DS configurations. I'll have to
> read more of the spec to see how/if this problem is being solved
> there.
>
In DS its simple, there is no extension - annotations don't support
inheritance. But you can use as many annotations, so instead of doing
annotation B extends annotation A and then use B, you use A and B.
Carsten
> Regards,
> Justin
>
> On Wed, Oct 15, 2014 at 2:24 AM, Carsten Ziegeler
> wrote:
>> In general, using typed objects is the preferred way to go, so I think a
>> configuration object should be a type object and return configuration
>> values in the correct type. Let's not fall back into the 80s and fiddle
>> around with string conversions all over the place.
>> Having a type for a configuration removes also the need for those ugly
>> name constants and we could hopefully also get away with having ugly
>> constants for default values.
>>
>> So what about using the approach we use in the new Declarative Service
>> specification and you define a configuration as an annotation:
>>
>> public @interface MyConfiguration {
>>
>>int port() default 465;
>>
>>String host() default "localhost";
>>
>>String userId;
>> }
>>
>> This leaves us with a single place to define a type configuration object
>> in combination with default values. We then define simple mapping rules
>> from names to resource names.
>>
>> And we should also support *all* java types not just those JCR supports.
>> Internally all numbers can be stored as long but the configuration
>> object gives you an integer, char whatever.
>>
>> This is how I would like to deal with configurations in code.
>>
>> Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert wrote: > ...this does not match the experience of our projects. we need those > parameters only in rare occasions directly > in the scripts (e.g. sightly)... As usual, IMO having a shared list of use cases (wiki?) would help a lot in getting consensus on what's needed and how to get there. ATM it looks like there are quite different visions of this stuff. -Bertrand
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
>[...] But to my >mind, one of the key targets for this new configuration structure is >scripts. this does not match the experience of our projects. we need those parameters only in rare occasions directly in the scripts (e.g. sightly), and in most time in the java code (models the scripts, different layers of business logic). but of course your experience may be different. stefan
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Carsten,
I have two concerns with this model:
1) Creating an annotation class can be a bit heavyweight. If I want to
just store a common value used across multiple scripts, doing so would
require creating this class, compiling it, deploying the bundle, etc.
vs. just adding a node property and referencing the property name from
my scripts (the constant is a nice-to-have, but not strictly
necessary). This is a non-issue for DS because the configuration
annotation is tightly coupled with the configured component. But to my
mind, one of the key targets for this new configuration structure is
scripts.
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'm also a bit concerned about the use of annotations in this way
because they can't be extended (at least I think this is true). I'm
not sure if this is a solved issue for DS configurations. I'll have to
read more of the spec to see how/if this problem is being solved
there.
Regards,
Justin
On Wed, Oct 15, 2014 at 2:24 AM, Carsten Ziegeler wrote:
> In general, using typed objects is the preferred way to go, so I think a
> configuration object should be a type object and return configuration
> values in the correct type. Let's not fall back into the 80s and fiddle
> around with string conversions all over the place.
> Having a type for a configuration removes also the need for those ugly
> name constants and we could hopefully also get away with having ugly
> constants for default values.
>
> So what about using the approach we use in the new Declarative Service
> specification and you define a configuration as an annotation:
>
> public @interface MyConfiguration {
>
>int port() default 465;
>
>String host() default "localhost";
>
>String userId;
> }
>
> This leaves us with a single place to define a type configuration object
> in combination with default values. We then define simple mapping rules
> from names to resource names.
>
> And we should also support *all* java types not just those JCR supports.
> Internally all numbers can be stored as long but the configuration
> object gives you an integer, char whatever.
>
> This is how I would like to deal with configurations in code.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
>However, one downside would be that you don't have hierarchical >configurations or maps - just scalar types and arrays of it. support for maps we can add using a helper method - internally its stored as string array anyway. hierarchical configurations could be modeled using annotation properties referencing other annotations - but the DS spec forbids this so i would vote to not support it. but an application could provide multiple configuration annotation types, e.g. one per aspect, so you do not have to define one single mega annotation with dozens of unrelated configuration properties. stefan
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Am 15.10.14 um 10:56 schrieb Stefan Seifert: > >>> do you have a link where such a concept is defined in context of the >>> new DS specification? using the same concept as a (new) DS version >>> would be plus. >> Sure, the spec can be found here >> https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190- >> Declarative_Services_Enhancements.pdf > > cool. chapter 5.6 precisely describes the supported types and coercion rules, > we should implement it exactly the same way. > in my view this decides whether to use a plain interface or an annotation > type - do it the same way as DS (will be) doing it: with annotation types. I would suggest so :) However, one downside would be that you don't have hierarchical configurations or maps - just scalar types and arrays of it. Carsten > > stefan > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
>> do you have a link where such a concept is defined in context of the >> new DS specification? using the same concept as a (new) DS version >> would be plus. >Sure, the spec can be found here >https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190- >Declarative_Services_Enhancements.pdf cool. chapter 5.6 precisely describes the supported types and coercion rules, we should implement it exactly the same way. in my view this decides whether to use a plain interface or an annotation type - do it the same way as DS (will be) doing it: with annotation types. stefan
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Am 15.10.14 um 09:01 schrieb Stefan Seifert:
> hello carsten.
>
> like it! so each application defines one (or multiple) of such
> configuration annotation classes. the first get on an configuration
> object would expect an annotation class, and the second would be nice
> typed access to a configuration value. providing additional metadata
> per configuration parameter (e.g. for a configuration editor) would
> still be possible by adding annotations to the annotation methods.
>
> of course we somewhat misuse the annotation concept here because it's
> never used as annotation at all - but it works quite well and is very
> comfortable. the only drawback i see that such annotations will be
> presented as well to users in their IDEs when typing @... to see what
> annotations are available to annotate their classes.
Right, but given that you already see hundreds of annotations there...
>
> do you have a link where such a concept is defined in context of the
> new DS specification? using the same concept as a (new) DS version
> would be plus.
Sure, the spec can be found here
https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf
>
> wouldn't it be an option to use a plain interface with default values
> as annotations? this comes close to what sling models supports
> today.
Yeah, sure - but I kind of like the more compact notation of an
annotation compared to having to annotate each field in the interface.
And an interface can define arbitrary methods, with arguments, complex
objects as return types etc. On the other hand annotations provide
exactly what you need for a configuration, the basic types and arrays
of those (ok, there is also Class allowed as a type).
I would be fine with going with interfaces as well - as long as we
have typed configurations objects which are a) easy to describe and
b) easy to use.
>
> my statement about "support only types from JCR" was not precise - i
> meant support all primitive types including string array plus map,
> but no custom or more advanced objects, because this would make
> things really complicated. currently a subset of primitive types is
> supported [1].
Ok.
Regards
Carsten
>
> stefan
>
> [1]
> http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions
>
>
>
>
>
>> -Original Message----- From: Carsten Ziegeler
>> [mailto:cziege...@apache.org] Sent: Wednesday, October 15, 2014
>> 8:24 AM To: dev@sling.apache.org Subject: Re: FW: [PROPOSAL]
>> Context-specific configuration for Apache Sling, Multitenancy
>>
>> In general, using typed objects is the preferred way to go, so I
>> think a configuration object should be a type object and return
>> configuration values in the correct type. Let's not fall back into
>> the 80s and fiddle around with string conversions all over the
>> place. Having a type for a configuration removes also the need for
>> those ugly name constants and we could hopefully also get away with
>> having ugly constants for default values.
>>
>> So what about using the approach we use in the new Declarative
>> Service specification and you define a configuration as an
>> annotation:
>>
>> public @interface MyConfiguration {
>>
>> int port() default 465;
>>
>> String host() default "localhost";
>>
>> String userId; }
>>
>> This leaves us with a single place to define a type configuration
>> object in combination with default values. We then define simple
>> mapping rules from names to resource names.
>>
>> And we should also support *all* java types not just those JCR
>> supports. Internally all numbers can be stored as long but the
>> configuration object gives you an integer, char whatever.
>>
>> This is how I would like to deal with configurations in code.
>>
>> Carsten
>>
>> -- Carsten Ziegeler Adobe Research Switzerland
>> cziege...@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello carsten.
like it! so each application defines one (or multiple) of such configuration
annotation classes. the first get on an configuration object would expect an
annotation class, and the second would be nice typed access to a configuration
value. providing additional metadata per configuration parameter (e.g. for a
configuration editor) would still be possible by adding annotations to the
annotation methods.
of course we somewhat misuse the annotation concept here because it's never
used as annotation at all - but it works quite well and is very comfortable.
the only drawback i see that such annotations will be presented as well to
users in their IDEs when typing @... to see what annotations are available to
annotate their classes.
do you have a link where such a concept is defined in context of the new DS
specification? using the same concept as a (new) DS version would be plus.
wouldn't it be an option to use a plain interface with default values as
annotations? this comes close to what sling models supports today.
my statement about "support only types from JCR" was not precise - i meant
support all primitive types including string array plus map, but no custom or
more advanced objects, because this would make things really complicated.
currently a subset of primitive types is supported [1].
stefan
[1] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions
>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Wednesday, October 15, 2014 8:24 AM
>To: dev@sling.apache.org
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>In general, using typed objects is the preferred way to go, so I think a
>configuration object should be a type object and return configuration
>values in the correct type. Let's not fall back into the 80s and fiddle
>around with string conversions all over the place.
>Having a type for a configuration removes also the need for those ugly
>name constants and we could hopefully also get away with having ugly
>constants for default values.
>
>So what about using the approach we use in the new Declarative Service
>specification and you define a configuration as an annotation:
>
>public @interface MyConfiguration {
>
> int port() default 465;
>
> String host() default "localhost";
>
> String userId;
>}
>
>This leaves us with a single place to define a type configuration object
>in combination with default values. We then define simple mapping rules
>from names to resource names.
>
>And we should also support *all* java types not just those JCR supports.
>Internally all numbers can be stored as long but the configuration
>object gives you an integer, char whatever.
>
>This is how I would like to deal with configurations in code.
>
>Carsten
>
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello justin.
i understand you concerns and see what you are pointing at. i hit the problem
as well at the same time wanting to have single valuemap with all parameters
and application separation or parameter names. i'm open to removing the
parameter<> stuff from the main API, it can always added as a layer on-top.
but carsten introduced a new idea, lets discuss this first.
stefan
>-Original Message-
>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
>Justin Edelson
>Sent: Wednesday, October 15, 2014 2:50 AM
>To: dev@sling.apache.org
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>Hi Stefan,
>To me, this sounds a bit schizophrenic - you're saying that the
>preferred way is to use a Parameter object, but that we need to
>support String-based lookup. And I'm not actually sure what "which
>type belongs to which string constant" actually means.
>
>Above all, this seems to create a confusing API. Since the expectation
>is that String-based lookups will work consistently, there's
>effectively no way to use the extra data within the Parameter object
>inside the lookup mechanism. For example, you mentioned the idea of
>using the application ID from the Parameter object as a way of
>expressing scope. But of course, this can't actually happen because
>there would be no way to do this with just Strings.
>
>I also personally find the setting of the default at the Parameter
>level a bit confusing. IME, defaults are *very* context-sensitive,
>whereas (if I understand) the Parameter objects are meant to be used
>across-contexts.
>
>All of which is to say that I would rather see the API have a clean
>separation between configuration lookup (which can be done purely with
>Strings) and Parameter definition. Or, to put in AEM terms, separate
>the functionality common to author & publish (configuration lookup)
>from the author-side functionality (parameter defintion which leads to
>editing).
>
>At this point, Configuration just becomes Map. The
>keys are are the application IDs and the resulting maps are the actual
>configurations for that application (which frankly I'd rather see
>called 'component' but that's neither here nor there). The only
>deviation I'd suggest from normal Map behavior is that
>config.get("non-existing-application-id") should return an empty
>ValueMap. This would allow you to do null-safe chaining, e.g.
>config.get("foo").get("bar") could return null, but never throw an NPE
>(unless config itself is null)
>
>If developers choose to adopt the Parameter objects, that's fine.
>Perhaps we even should have a utility method
>ConfigurationUtils.get(config, param) which calls
>config.get(param.getApplicationId()).get(param.getName(),
>param.getType()) But this is an optional step and the use of Parameter
>objects isn't implied by the Configuration API.
>
>Regards,
>Justin
>
>On Tue, Oct 14, 2014 at 6:58 PM, Stefan Seifert
>wrote:
>> hello justin.
>>
>> yes, this is my expectation for the java code. if you only provide a string-
>based access to configuration parameter every developer will start to create a
>"NameConstants" class to define the much-used property names (or you will
>provide such a class as part of your applications API). then the developer has
>to remember which type belongs to which string constant. then you have to find
>a way where you define the default values of a parameter, and describe its
>edit mode capabilities. all this is covered by building a structured parameter
>definition. but yes, it started as a simple helper class with constants to
>easy access all existing parameters of an application.
>>
>> as a bonus there is an abstract implementation of the "ParameterProvider"
>interface which just reads the static fields of such a class and provides the
>defined parameters as OSGi service to the config infrastructure.
>>
>> you still need the string-based (or map-based) access for usecases like
>sightly templates where it is not so easy or uncommon to use constants for
>accessing map values. but in our experience the parameters are used in most
>cases in the java business logic behind the presentation layer, not in the
>presentation layer (scripts) itself. and of course the lazy developers can use
>this access at well in java code...
>>
>> stefan
>>
>>
>>>-Original Message-
>>>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
>>>Justin Edelson
>>>Sent: Tuesday, October 14, 2014 11:32 PM
>>>To: dev@sling.apache.org
>
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
In general, using typed objects is the preferred way to go, so I think a
configuration object should be a type object and return configuration
values in the correct type. Let's not fall back into the 80s and fiddle
around with string conversions all over the place.
Having a type for a configuration removes also the need for those ugly
name constants and we could hopefully also get away with having ugly
constants for default values.
So what about using the approach we use in the new Declarative Service
specification and you define a configuration as an annotation:
public @interface MyConfiguration {
int port() default 465;
String host() default "localhost";
String userId;
}
This leaves us with a single place to define a type configuration object
in combination with default values. We then define simple mapping rules
from names to resource names.
And we should also support *all* java types not just those JCR supports.
Internally all numbers can be stored as long but the configuration
object gives you an integer, char whatever.
This is how I would like to deal with configurations in code.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Stefan,
To me, this sounds a bit schizophrenic - you're saying that the
preferred way is to use a Parameter object, but that we need to
support String-based lookup. And I'm not actually sure what "which
type belongs to which string constant" actually means.
Above all, this seems to create a confusing API. Since the expectation
is that String-based lookups will work consistently, there's
effectively no way to use the extra data within the Parameter object
inside the lookup mechanism. For example, you mentioned the idea of
using the application ID from the Parameter object as a way of
expressing scope. But of course, this can't actually happen because
there would be no way to do this with just Strings.
I also personally find the setting of the default at the Parameter
level a bit confusing. IME, defaults are *very* context-sensitive,
whereas (if I understand) the Parameter objects are meant to be used
across-contexts.
All of which is to say that I would rather see the API have a clean
separation between configuration lookup (which can be done purely with
Strings) and Parameter definition. Or, to put in AEM terms, separate
the functionality common to author & publish (configuration lookup)
from the author-side functionality (parameter defintion which leads to
editing).
At this point, Configuration just becomes Map. The
keys are are the application IDs and the resulting maps are the actual
configurations for that application (which frankly I'd rather see
called 'component' but that's neither here nor there). The only
deviation I'd suggest from normal Map behavior is that
config.get("non-existing-application-id") should return an empty
ValueMap. This would allow you to do null-safe chaining, e.g.
config.get("foo").get("bar") could return null, but never throw an NPE
(unless config itself is null)
If developers choose to adopt the Parameter objects, that's fine.
Perhaps we even should have a utility method
ConfigurationUtils.get(config, param) which calls
config.get(param.getApplicationId()).get(param.getName(),
param.getType()) But this is an optional step and the use of Parameter
objects isn't implied by the Configuration API.
Regards,
Justin
On Tue, Oct 14, 2014 at 6:58 PM, Stefan Seifert wrote:
> hello justin.
>
> yes, this is my expectation for the java code. if you only provide a
> string-based access to configuration parameter every developer will start to
> create a "NameConstants" class to define the much-used property names (or you
> will provide such a class as part of your applications API). then the
> developer has to remember which type belongs to which string constant. then
> you have to find a way where you define the default values of a parameter,
> and describe its edit mode capabilities. all this is covered by building a
> structured parameter definition. but yes, it started as a simple helper class
> with constants to easy access all existing parameters of an application.
>
> as a bonus there is an abstract implementation of the "ParameterProvider"
> interface which just reads the static fields of such a class and provides the
> defined parameters as OSGi service to the config infrastructure.
>
> you still need the string-based (or map-based) access for usecases like
> sightly templates where it is not so easy or uncommon to use constants for
> accessing map values. but in our experience the parameters are used in most
> cases in the java business logic behind the presentation layer, not in the
> presentation layer (scripts) itself. and of course the lazy developers can
> use this access at well in java code...
>
> stefan
>
>
>>-----Original Message-
>>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
>>Justin Edelson
>>Sent: Tuesday, October 14, 2014 11:32 PM
>>To: dev@sling.apache.org
>>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>>Multitenancy
>>
>>Hi Stefan,
>>Thanks for clarifying. So is it accurate to say that your expectation
>>that the *vast* majority of clients to use a strongly-typed Parameter
>>object rather than doing a simple String lookup?
>>
>>To me, this seems very heavyweight, but maybe I am being short sighted
>>(or lazy).
>>
>>But on the other hand, if you expect clients to use Paramter objects,
>>why support String lookup at all?
>>
>>Justin
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello justin. yes, this is my expectation for the java code. if you only provide a string-based access to configuration parameter every developer will start to create a "NameConstants" class to define the much-used property names (or you will provide such a class as part of your applications API). then the developer has to remember which type belongs to which string constant. then you have to find a way where you define the default values of a parameter, and describe its edit mode capabilities. all this is covered by building a structured parameter definition. but yes, it started as a simple helper class with constants to easy access all existing parameters of an application. as a bonus there is an abstract implementation of the "ParameterProvider" interface which just reads the static fields of such a class and provides the defined parameters as OSGi service to the config infrastructure. you still need the string-based (or map-based) access for usecases like sightly templates where it is not so easy or uncommon to use constants for accessing map values. but in our experience the parameters are used in most cases in the java business logic behind the presentation layer, not in the presentation layer (scripts) itself. and of course the lazy developers can use this access at well in java code... stefan >-Original Message- >From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of >Justin Edelson >Sent: Tuesday, October 14, 2014 11:32 PM >To: dev@sling.apache.org >Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >Hi Stefan, >Thanks for clarifying. So is it accurate to say that your expectation >that the *vast* majority of clients to use a strongly-typed Parameter >object rather than doing a simple String lookup? > >To me, this seems very heavyweight, but maybe I am being short sighted >(or lazy). > >But on the other hand, if you expect clients to use Paramter objects, >why support String lookup at all? > >Justin
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Stefan,
Thanks for clarifying. So is it accurate to say that your expectation
that the *vast* majority of clients to use a strongly-typed Parameter
object rather than doing a simple String lookup?
To me, this seems very heavyweight, but maybe I am being short sighted
(or lazy).
But on the other hand, if you expect clients to use Paramter objects,
why support String lookup at all?
Justin
On Tue, Oct 14, 2014 at 11:24 AM, Stefan Seifert wrote:
> hello justin.
>
> as described in [1] we currently took the design decision to have only a flat
> parameter list, namespacing can and has to be done inside the parameter
> names. the goal was to really support the full configuration in a single
> value map. but i'm aware this may not be sufficient, but wanted to start
> simple in this case. each parameter definition already has an application ID
> assigned as well, so technically it would not be a problem to have a
> parameter namespace per application/library that provides the parameters.
> i've not found yet a nice client API solution for this - chaining two get
> methods as in your example would be a solution.
>
> as the configuration API is designed to work with parameter constants holding
> the parameter definition [2] this chaining would only be needed if the
> configuration value map is accessed using string values. if using the
> parameter definition constant all information is in place. parameter
> definitions can have more metadata if a configuration editor is supported as
> well, see example [3] resulting in [4].
>
> stefan
>
> [1] http://wcm.io/config/api/usage-spi.html#Preconditions_and_limitations
> [2] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions
> [3]
> https://github.com/wcm-io/wcm-io/blob/master/samples/config-sample-app/src/main/java/io/wcm/samples/configsampleapp/config/Params.java
> [4] http://wcm.io/config/editor/usage.html
>
>
>>-Original Message-
>>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
>>Justin Edelson
>>Sent: Tuesday, October 14, 2014 4:58 PM
>>To: dev@sling.apache.org
>>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>>Multitenancy
>>
>>Hi Dominik,
>>Thanks for this link, but I'm still confused about scoping. Looking at
>>http://wcm.io/config/api/usage-api.html, it seems like a Configuration
>>object is essentially just a ValueMap. In a non-trivial application,
>>it seems like you need some kind of namespace for configuration
>>properties. For example, let's say that I'm integrating with multiple
>>OAuth services. I thus have multiple configuration properties which
>>are natually named 'secretKey'. Do I need to prefix these property
>>keys with the service name, e.g. "facebook.secretKey" and
>>"linkedin.secretKey"? I would expect that I could have a Map of Maps
>>so I could say something like
>>configuration.get("facebook").get("secretKey") ?
>>
>>How is this embodied in the API? Are "facebook" and "linkedin" applications?
>>
>>Justin
>>
>>On Tue, Oct 14, 2014 at 5:13 AM, Dominik Süß wrote:
>>> Hi everyone,
>>>
>>> I guess people yet just had no chance to dig into the proposal since there
>>> are a lot of scenarios adressed throught this proposal. As far as I
>>> understood the API & SPI the main driver for this proposal is the massive
>>> multisite scenario as described in the mentioned wiki page. Key aspects
>>> seem to be to get an aggregated context specific view for a configuration
>>> while lookup aspects (such as where to look up the configs and how
>>> inheritance is solved) are designed in a pluggable way that allows to
>>> implement application specific behavior.
>>>
>>> From offlist discussions I know that there might be some confusion around
>>> how the scoping should work so I just wanted to highlight the mentioned
>>> link [3] that might eliminate confusion around the wording (especially
>>> appliation).
>>>
>>> IMHO it would be an extremely valuable addition providing sufficient
>>> flexiblity to solve all the cases I do have in mind while establishing one
>>> unified methodology to deal with all the non osgi configuration without
>>> rewriting casespecific lookup (boilerplate) code over and over again.
>>>
>>> Best regards,
>>> Dominik
>>>
>>> [3] http://wcm.io/config/api/terminology.html
>>>
>>>
>>>
>>> On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert
>
RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
hello justin.
as described in [1] we currently took the design decision to have only a flat
parameter list, namespacing can and has to be done inside the parameter names.
the goal was to really support the full configuration in a single value map.
but i'm aware this may not be sufficient, but wanted to start simple in this
case. each parameter definition already has an application ID assigned as well,
so technically it would not be a problem to have a parameter namespace per
application/library that provides the parameters. i've not found yet a nice
client API solution for this - chaining two get methods as in your example
would be a solution.
as the configuration API is designed to work with parameter constants holding
the parameter definition [2] this chaining would only be needed if the
configuration value map is accessed using string values. if using the parameter
definition constant all information is in place. parameter definitions can have
more metadata if a configuration editor is supported as well, see example [3]
resulting in [4].
stefan
[1] http://wcm.io/config/api/usage-spi.html#Preconditions_and_limitations
[2] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions
[3]
https://github.com/wcm-io/wcm-io/blob/master/samples/config-sample-app/src/main/java/io/wcm/samples/configsampleapp/config/Params.java
[4] http://wcm.io/config/editor/usage.html
>-Original Message-
>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
>Justin Edelson
>Sent: Tuesday, October 14, 2014 4:58 PM
>To: dev@sling.apache.org
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>Hi Dominik,
>Thanks for this link, but I'm still confused about scoping. Looking at
>http://wcm.io/config/api/usage-api.html, it seems like a Configuration
>object is essentially just a ValueMap. In a non-trivial application,
>it seems like you need some kind of namespace for configuration
>properties. For example, let's say that I'm integrating with multiple
>OAuth services. I thus have multiple configuration properties which
>are natually named 'secretKey'. Do I need to prefix these property
>keys with the service name, e.g. "facebook.secretKey" and
>"linkedin.secretKey"? I would expect that I could have a Map of Maps
>so I could say something like
>configuration.get("facebook").get("secretKey") ?
>
>How is this embodied in the API? Are "facebook" and "linkedin" applications?
>
>Justin
>
>On Tue, Oct 14, 2014 at 5:13 AM, Dominik Süß wrote:
>> Hi everyone,
>>
>> I guess people yet just had no chance to dig into the proposal since there
>> are a lot of scenarios adressed throught this proposal. As far as I
>> understood the API & SPI the main driver for this proposal is the massive
>> multisite scenario as described in the mentioned wiki page. Key aspects
>> seem to be to get an aggregated context specific view for a configuration
>> while lookup aspects (such as where to look up the configs and how
>> inheritance is solved) are designed in a pluggable way that allows to
>> implement application specific behavior.
>>
>> From offlist discussions I know that there might be some confusion around
>> how the scoping should work so I just wanted to highlight the mentioned
>> link [3] that might eliminate confusion around the wording (especially
>> appliation).
>>
>> IMHO it would be an extremely valuable addition providing sufficient
>> flexiblity to solve all the cases I do have in mind while establishing one
>> unified methodology to deal with all the non osgi configuration without
>> rewriting casespecific lookup (boilerplate) code over and over again.
>>
>> Best regards,
>> Dominik
>>
>> [3] http://wcm.io/config/api/terminology.html
>>
>>
>>
>> On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert
>> wrote:
>>
>>> p.s. url [1] is wrong - it should be
>>> https://cwiki.apache.org/confluence/x/So2uAg
>>>
>>> -Original Message-
>>> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>>> Sent: Saturday, October 04, 2014 1:54 AM
>>> To: dev@sling.apache.org
>>> Subject: [PROPOSAL] Context-specific configuration for Apache Sling,
>>> Multitenancy
>>>
>>> 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
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi Dominik,
Thanks for this link, but I'm still confused about scoping. Looking at
http://wcm.io/config/api/usage-api.html, it seems like a Configuration
object is essentially just a ValueMap. In a non-trivial application,
it seems like you need some kind of namespace for configuration
properties. For example, let's say that I'm integrating with multiple
OAuth services. I thus have multiple configuration properties which
are natually named 'secretKey'. Do I need to prefix these property
keys with the service name, e.g. "facebook.secretKey" and
"linkedin.secretKey"? I would expect that I could have a Map of Maps
so I could say something like
configuration.get("facebook").get("secretKey") ?
How is this embodied in the API? Are "facebook" and "linkedin" applications?
Justin
On Tue, Oct 14, 2014 at 5:13 AM, Dominik Süß wrote:
> Hi everyone,
>
> I guess people yet just had no chance to dig into the proposal since there
> are a lot of scenarios adressed throught this proposal. As far as I
> understood the API & SPI the main driver for this proposal is the massive
> multisite scenario as described in the mentioned wiki page. Key aspects
> seem to be to get an aggregated context specific view for a configuration
> while lookup aspects (such as where to look up the configs and how
> inheritance is solved) are designed in a pluggable way that allows to
> implement application specific behavior.
>
> From offlist discussions I know that there might be some confusion around
> how the scoping should work so I just wanted to highlight the mentioned
> link [3] that might eliminate confusion around the wording (especially
> appliation).
>
> IMHO it would be an extremely valuable addition providing sufficient
> flexiblity to solve all the cases I do have in mind while establishing one
> unified methodology to deal with all the non osgi configuration without
> rewriting casespecific lookup (boilerplate) code over and over again.
>
> Best regards,
> Dominik
>
> [3] http://wcm.io/config/api/terminology.html
>
>
>
> On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert
> wrote:
>
>> p.s. url [1] is wrong - it should be
>> https://cwiki.apache.org/confluence/x/So2uAg
>>
>> -Original Message-
>> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>> Sent: Saturday, October 04, 2014 1:54 AM
>> To: dev@sling.apache.org
>> Subject: [PROPOSAL] Context-specific configuration for Apache Sling,
>> Multitenancy
>>
>> 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/
>>
>>
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi, It looks like a well documented and complete contribution covering non OSGi configuration and dealing with multiple contexts. I think that is a widely held generic use case, even if for many projects only one context is considered. As such, I think it has a place in Sling, if only to save downstream products going through the expense and pain of implementing the same. I am not certain where it should go. Probably a contrib area under trunk rather than something that is central to starting a Sling instance. On that basis, provided all barriers to contribution to Sling are cleared and copyright can safely be assigned to the ASF, I am +1 on accepting the contribution (with recognition and thanks for the hard work involved). Best Regards Ian On 14 October 2014 10:13, Dominik Süß wrote: > Hi everyone, > > I guess people yet just had no chance to dig into the proposal since there > are a lot of scenarios adressed throught this proposal. As far as I > understood the API & SPI the main driver for this proposal is the massive > multisite scenario as described in the mentioned wiki page. Key aspects > seem to be to get an aggregated context specific view for a configuration > while lookup aspects (such as where to look up the configs and how > inheritance is solved) are designed in a pluggable way that allows to > implement application specific behavior. > > From offlist discussions I know that there might be some confusion around > how the scoping should work so I just wanted to highlight the mentioned > link [3] that might eliminate confusion around the wording (especially > appliation). > > IMHO it would be an extremely valuable addition providing sufficient > flexiblity to solve all the cases I do have in mind while establishing one > unified methodology to deal with all the non osgi configuration without > rewriting casespecific lookup (boilerplate) code over and over again. > > Best regards, > Dominik > > [3] http://wcm.io/config/api/terminology.html > > > > On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert > wrote: > >> p.s. url [1] is wrong - it should be >> https://cwiki.apache.org/confluence/x/So2uAg >> >> -Original Message- >> From: Stefan Seifert [mailto:sseif...@pro-vision.de] >> Sent: Saturday, October 04, 2014 1:54 AM >> To: dev@sling.apache.org >> Subject: [PROPOSAL] Context-specific configuration for Apache Sling, >> Multitenancy >> >> 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/ >> >>
Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
Hi everyone, I guess people yet just had no chance to dig into the proposal since there are a lot of scenarios adressed throught this proposal. As far as I understood the API & SPI the main driver for this proposal is the massive multisite scenario as described in the mentioned wiki page. Key aspects seem to be to get an aggregated context specific view for a configuration while lookup aspects (such as where to look up the configs and how inheritance is solved) are designed in a pluggable way that allows to implement application specific behavior. >From offlist discussions I know that there might be some confusion around how the scoping should work so I just wanted to highlight the mentioned link [3] that might eliminate confusion around the wording (especially appliation). IMHO it would be an extremely valuable addition providing sufficient flexiblity to solve all the cases I do have in mind while establishing one unified methodology to deal with all the non osgi configuration without rewriting casespecific lookup (boilerplate) code over and over again. Best regards, Dominik [3] http://wcm.io/config/api/terminology.html On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert wrote: > p.s. url [1] is wrong - it should be > https://cwiki.apache.org/confluence/x/So2uAg > > -Original Message- > From: Stefan Seifert [mailto:sseif...@pro-vision.de] > Sent: Saturday, October 04, 2014 1:54 AM > To: dev@sling.apache.org > Subject: [PROPOSAL] Context-specific configuration for Apache Sling, > Multitenancy > > 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/ > >
