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 bdelacre...@apache.org wrote: Hi Stefan, On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert sseif...@pro-vision.de 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
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 sseif...@pro-vision.de 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
hello Bertrand. On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert sseif...@pro-vision.de 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 2:08 PM, Stefan Seifert sseif...@pro-vision.de 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
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 MapString, ValueMap. 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 sseif...@pro-vision.de 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 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
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
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 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
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
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 cziege...@apache.org 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
[...] 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
On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert sseif...@pro-vision.de 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 cziege...@apache.org
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
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 sseif...@pro-vision.de 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üß dominik.su...@gmail.com 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 sseif...@pro-vision.de 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 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üß dominik.su...@gmail.com 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 sseif...@pro-vision.de 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
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üß dominik.su...@gmail.com 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 sseif...@pro-vision.de 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
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 sseif...@pro-vision.de 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üß dominik.su...@gmail.com 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 sseif...@pro-vision.de 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
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, 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 MapString, ValueMap. 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 sseif...@pro-vision.de 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
FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy
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/
