[PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
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/

Reply | Threaded
Open this post in threaded view
|

FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
p.s. url [1] is wrong - it should be https://cwiki.apache.org/confluence/x/So2uAg

-----Original Message-----
From: Stefan Seifert [mailto:[hidden email]]
Sent: Saturday, October 04, 2014 1:54 AM
To: [hidden email]
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/

Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Dominik Süß
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 <[hidden email]>
wrote:

> p.s. url [1] is wrong - it should be
> https://cwiki.apache.org/confluence/x/So2uAg
>
> -----Original Message-----
> From: Stefan Seifert [mailto:[hidden email]]
> Sent: Saturday, October 04, 2014 1:54 AM
> To: [hidden email]
> 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/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Ian Boston
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üß <[hidden email]> 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 <[hidden email]>
> wrote:
>
>> p.s. url [1] is wrong - it should be
>> https://cwiki.apache.org/confluence/x/So2uAg
>>
>> -----Original Message-----
>> From: Stefan Seifert [mailto:[hidden email]]
>> Sent: Saturday, October 04, 2014 1:54 AM
>> To: [hidden email]
>> 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/
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

justzzzz
In reply to this post by Dominik Süß
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üß <[hidden email]> 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 <[hidden email]>
> wrote:
>
>> p.s. url [1] is wrong - it should be
>> https://cwiki.apache.org/confluence/x/So2uAg
>>
>> -----Original Message-----
>> From: Stefan Seifert [mailto:[hidden email]]
>> Sent: Saturday, October 04, 2014 1:54 AM
>> To: [hidden email]
>> 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/
>>
>>
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
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: [hidden email] [mailto:[hidden email]] On Behalf Of
>Justin Edelson
>Sent: Tuesday, October 14, 2014 4:58 PM
>To: [hidden email]
>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üß <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> p.s. url [1] is wrong - it should be
>>> https://cwiki.apache.org/confluence/x/So2uAg
>>>
>>> -----Original Message-----
>>> From: Stefan Seifert [mailto:[hidden email]]
>>> Sent: Saturday, October 04, 2014 1:54 AM
>>> To: [hidden email]
>>> 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/
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Alexander Klimetschek-2
In reply to this post by Stefan Seifert
I see 3 problems:

- allowing to hook in a custom lookup strategy and not defining a clear lookup & content model (too much magic in such things is bad, it should be obvious by just browsing the JCR, just as with resource types)
- the idea of putting configurations itself under /content; configs have a different management lifecycle and ACLs
- complexity of the API, Parameter<> generics just replicate the valuemap, but in what seems to me like an overengineered fashion & one that shields too much from the power of JCR, which might lead to have people invent custom string formats instead of using JCR properties; in reality, 80% of properties are strings, 10% each are boolean or integers (subjective experience stats TM :))

Cheers,
Alex

On 03.10.2014, at 16:53, Stefan Seifert <[hidden email]> wrote:

> this proposal is about context-specific configuration, that means configuration that cannot be stored as OSGi configurations. OSGi configurations are always system-wide, so they are not well-suited for storing configurations per context e.g. site, region or tenant. this is related to the multitenancy discussion on this list, see [1] for a summary of the past discussion.
>
> we've implementation a solution for this and are currently thinking about donating it to Apache Sling. a documentation of what is currently implemented is at [2]. the most relevant pages you should read are [3], [4], [5], [6]. the implementation is based on the requirements from [7], although not all that is listed on that page is implemented currently (but a good deal of it). source code is at [8], a sample application at [9].
>
> the current implementation is targeted to a specific sling-based CMS - but besides the configuration editor and the parameter persistence provider it does not depend on the CMS API but only on the Sling APIs, being technically suited to be donated to Apache Sling. it's already published under apache license 2.0.
>
> i'm interested if there is more need in the community for solving the requirements i've listed, and the solutions we have implemented for it. and if there are other sling committers who want to take part in its development and enhancement as well. although we're using the current implementation from wcm.io already in our projects nothing of it's current architecture is carved in stone and i'm open to broaden the scope of requirements it should support.
>
> WDYT?
>
> stefan
>
>
> [1] https://cwiki.apache.org/confluence/x/zJBcAg
> [2] http://wcm.io/config/
> [3] http://wcm.io/config/api/terminology.html
> [4] http://wcm.io/config/api/usage-api.html
> [5] http://wcm.io/config/api/usage-spi.html
> [6] http://wcm.io/config/editor/usage.html
> [7] https://wcm-io.atlassian.net/wiki/x/HIAH
> [8] https://github.com/wcm-io/wcm-io/tree/master/config
> [9] http://wcm.io/samples/config-sample-app/
>

Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

justzzzz
In reply to this post by Stefan Seifert
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of
>>Justin Edelson
>>Sent: Tuesday, October 14, 2014 4:58 PM
>>To: [hidden email]
>>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üß <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>
>>>> p.s. url [1] is wrong - it should be
>>>> https://cwiki.apache.org/confluence/x/So2uAg
>>>>
>>>> -----Original Message-----
>>>> From: Stefan Seifert [mailto:[hidden email]]
>>>> Sent: Saturday, October 04, 2014 1:54 AM
>>>> To: [hidden email]
>>>> 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/
>>>>
>>>>
Reply | Threaded
Open this post in threaded view
|

RE: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
In reply to this post by Alexander Klimetschek-2
hello alex.

>-----Original Message-----
>From: Alexander Klimetschek [mailto:[hidden email]]
>Sent: Tuesday, October 14, 2014 10:13 PM
>To: [hidden email]
>Subject: Re: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>I see 3 problems:
>
>- allowing to hook in a custom lookup strategy and not defining a clear lookup
>& content model (too much magic in such things is bad, it should be obvious by
>just browsing the JCR, just as with resource types)
>- the idea of putting configurations itself under /content; configs have a
>different management lifecycle and ACLs

to shorten a discussion i've written a persistence provider that stores exactly you want it - in a shadow structure below /conf. this was only a small deviation from the existing persistence provider, documentation of "ConfStructurePersistenceProvider" at [1], impl at [2]

still i see a need for a pluggable architecture at this point. starting on the green you are right. but we have already thousands of sling-based applications out there. and because no standard for context-specific configs existed in the past, every dev team has invented their own strategy having tens of thousands of sites with existing configuration. supporting them only needs an implementation of a custom PeristenceProvider, new configuration can be stored at /conf (the implementation supports multiple persistence providers for reading).

and not all configuration parameters are so sensitive that they cannot be stored together with content. we have configuration parameters like "list of news category names" or parameters to tweak the style or behavior of some marketing features on the site. they should be allowed to be configured by authors and are more or less part of the content. but let's not start philosophical discussions on that.


>- complexity of the API, Parameter<> generics just replicate the valuemap, but
>in what seems to me like an overengineered fashion & one that shields too much
>from the power of JCR, which might lead to have people invent custom string
>formats instead of using JCR properties; in reality, 80% of properties are
>strings, 10% each are boolean or integers (subjective experience stats TM :))

the Parameter<> generics only supports types supported by JCR (single and multi-valued), and a map which is stored in a string array internally.
see more on this topic in my answer to justins mail.


[1] http://wcm.io/config/core/persistence-providers.html
[2] https://github.com/wcm-io/wcm-io/blob/master/config/core/src/main/java/io/wcm/config/core/persistence/impl/ConfStructurePersistenceProvider.java

Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
In reply to this post by justzzzz
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: [hidden email] [mailto:[hidden email]] On Behalf Of
>Justin Edelson
>Sent: Tuesday, October 14, 2014 11:32 PM
>To: [hidden email]
>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
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

justzzzz
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<String, 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of
>>Justin Edelson
>>Sent: Tuesday, October 14, 2014 11:32 PM
>>To: [hidden email]
>>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
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
In reply to this post by justzzzz
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: [hidden email] [mailto:[hidden email]] On Behalf Of
>Justin Edelson
>Sent: Wednesday, October 15, 2014 2:50 AM
>To: [hidden email]
>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<String, 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 <[hidden email]>
>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: [hidden email] [mailto:[hidden email]] On Behalf Of
>>>Justin Edelson
>>>Sent: Tuesday, October 14, 2014 11:32 PM
>>>To: [hidden email]
>>>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
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert
In reply to this post by Carsten Ziegeler
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:[hidden email]]
>Sent: Wednesday, October 15, 2014 8:24 AM
>To: [hidden email]
>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
>[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Carsten Ziegeler
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:[hidden email]] Sent: Wednesday, October 15, 2014
>> 8:24 AM To: [hidden email] 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
>> [hidden email]


--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

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.

stefan
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert

>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
Reply | Threaded
Open this post in threaded view
|

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

justzzzz
In reply to this post by Carsten Ziegeler
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 <[hidden email]> 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
> [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

Stefan Seifert

>[...] 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
12