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

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

Bertrand Delacretaz
On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Ziegeler
In reply to this post by justzzzz
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 <[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]
>


--
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 Bertrand Delacretaz
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:[hidden email]]
>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 <[hidden email]>
>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
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 Stefan Seifert

>> 2) I'm assuming that the lookup key for these configuration objects is
>> the class name. IMHO, we need some kind of differentiator, see for
>> example my OAuth example earlier in this thread.
>>
>I haven't thought of this part yet, I've just stated my strong wish
>for strongly typed configuration objects :)

it seems as we would need some sort of factory-configuration for this usecase as well? this would be problematic in my initial approach with only a flat list of properties in a valuemap as well.

an oauth bundle would provide an annotation type class and mark it as "multiple" or "factory". the API has to provide a way to get lists of annotation class instances to iterate over. the configuration editor has to support it as well. should be possible, although it would make the API a bit more complex.

stefan
Reply | Threaded
Open this post in threaded view
|

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

Carsten Ziegeler
Am 17.10.14 um 12:02 schrieb Stefan Seifert:

>
>>> 2) I'm assuming that the lookup key for these configuration objects is
>>> the class name. IMHO, we need some kind of differentiator, see for
>>> example my OAuth example earlier in this thread.
>>>
>> I haven't thought of this part yet, I've just stated my strong wish
>> for strongly typed configuration objects :)
>
> it seems as we would need some sort of factory-configuration for this usecase as well? this would be problematic in my initial approach with only a flat list of properties in a valuemap as well.
>
> an oauth bundle would provide an annotation type class and mark it as "multiple" or "factory". the API has to provide a way to get lists of annotation class instances to iterate over. the configuration editor has to support it as well. should be possible, although it would make the API a bit more complex.
>

I'm just thinking out loud, especially as I don't have that much
experience in this area.

But what is the preferred way to get a configuration? I would assume
that you get a configuration for a key similar to the pid for OSGi
configurations. From an API point of view a

T[] getConfiguration(String key, Class<T> type);

for a single and

T[] getConfigurations(String key, Class<T> type);

for multiple would do?

Again, just talking out loud without thinking of anything else related
to this stuff.

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

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

Stefan Seifert

>But what is the preferred way to get a configuration? I would assume
>that you get a configuration for a key similar to the pid for OSGi
>configurations. From an API point of view a
>
>T[] getConfiguration(String key, Class<T> type);
>
>for a single and
>
>T[] getConfigurations(String key, Class<T> type);
>
>for multiple would do?


proposal how the API can be used:

---
Configuration config = resource.adaptTo(Configuration.class);

// single access
String value = config.get(MyTypedConfig.class).getParam1();

// multiple acces
MyTypedConfig[] myconfigs = config.getMultiple(MyTypedConfig.class);
String value = myconfigs[0].getParam1()
---

i thought about if we can get rid of the Configuration.class at all and directly use MyTypedConfig.class or MyTypedConfig[].class in the adaptTo() call, but i'm not sure if that’s working with annotation types. or use Configuration.class only in cases where you need string-based value map access.

i currently do not see a need for a "key" when accessing the typed configuration.

stefan
Reply | Threaded
Open this post in threaded view
|

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

Carsten Ziegeler
Am 17.10.14 um 12:26 schrieb Stefan Seifert:

>
>> But what is the preferred way to get a configuration? I would assume
>> that you get a configuration for a key similar to the pid for OSGi
>> configurations. From an API point of view a
>>
>> T[] getConfiguration(String key, Class<T> type);
>>
>> for a single and
>>
>> T[] getConfigurations(String key, Class<T> type);
>>
>> for multiple would do?
>
>
> proposal how the API can be used:
>
> ---
> Configuration config = resource.adaptTo(Configuration.class);
>
> // single access
> String value = config.get(MyTypedConfig.class).getParam1();
>
> // multiple acces
> MyTypedConfig[] myconfigs = config.getMultiple(MyTypedConfig.class);
> String value = myconfigs[0].getParam1()
> ---
>
> i thought about if we can get rid of the Configuration.class at all and directly use MyTypedConfig.class or MyTypedConfig[].class in the adaptTo() call, but i'm not sure if that’s working with annotation types. or use Configuration.class only in cases where you need string-based value map access.
>
> i currently do not see a need for a "key" when accessing the typed configuration.
>

Right, the resource path is the key - I'm fine with that.

I guess we need the Configuration for all use case where people don't
want to define their configuration type. Directly adapting to
MyTypedConfig or MyTypedConfig[] class is nice, but requires that you
register each and every configuration type through an adapter factory.
And if you want to use a different one, this gets difficult.

So I think adding an adaptTo method to Configuration might do  the trick:

MyTypedConfig =
resource.adaptTo(Configuration.class).adaptTo(MyTypedConfig.class);

The adaption within the implementation of the configuration class can be
done on the fly by creating a proxy.
We should check if
esource.adaptTo(Configuration.class).adaptTo(MyTypedConfig[].class)
would be implementable as well.

Carsten


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

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

Bertrand Delacretaz
In reply to this post by Stefan Seifert
Hi Stefan,

On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert <[hidden email]> wrote:
> ... https://cwiki.apache.org/confluence/x/1ATTAg ...

Thanks for this. Looking at your use-cases it feels like your context
is always derived from the current resource's position in the content
tree, am I correct?

If yes that explains why you suggest putting the configuration
alongside the content - but we might want to also support configs
stored under /conf or somewhere else safe. Quoting Alex K earlier in
this thread

>> ...configs have a different management lifecycle and ACLs than content ...

which can be true but not in your use cases, IIUC - so both options
probably make sense.

-Bertrand
Reply | Threaded
Open this post in threaded view
|

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

Stefan Seifert
hello Bertrand.

>On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert <[hidden email]>
>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

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 Carsten Ziegeler
hello carsten.

>So I think adding an adaptTo method to Configuration might do  the trick:
>
>MyTypedConfig =
>resource.adaptTo(Configuration.class).adaptTo(MyTypedConfig.class);
>
>The adaption within the implementation of the configuration class can be
>done on the fly by creating a proxy.
>We should check if
>esource.adaptTo(Configuration.class).adaptTo(MyTypedConfig[].class)
>would be implementable as well.

this is nice as well.

in this case the Configuration interface could be reduced to an extension of two other interfaces: ValueMap and Adaptable.

what is left to be defined is how the string-based access without annotation types is working then in single and multiple variant. it's not a s easy as in DS, because in DS the context is always a service with a flat property list. here we have an aggregated view of a big number of annotation types which may overlap in the defined property names.

stefan
Reply | Threaded
Open this post in threaded view
|

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

Bertrand Delacretaz
In reply to this post by Stefan Seifert
Hi Stefan,

On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

> Hi Stefan,
>
> On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Oliver Lietz
In reply to this post by Stefan Seifert
On Saturday 04 October 2014 01:53:38 Stefan Seifert wrote:

hi Stefan,

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

what's the status here? Will you move this project to Sling?

Is it possible to read/write configurations of the current resource only or
are configurations always collected up the tree?

Thanks,
O.

Reply | Threaded
Open this post in threaded view
|

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

Stefan Seifert
hello oliver.

>what's the status here? Will you move this project to Sling?

this is not decided yet, no precise plans yet. this depends if it is useful for a broader audience in the sling community and projects/applications built with sling. until then just try it out from wcm.io. additionally i wanted to experiment with carstens idea to define configuration parameters using annotation classes as defined in the new OSGi specifications, but i had found no time for this yet.
we already use this in production, but surely there is still room for improvement.


>Is it possible to read/write configurations of the current resource only or
>are configurations always collected up the tree?

this depends on the "configuration finder strategey" used. our intention is that the configuration is normally not in the current resource, but always somewhere up in the tree. or in a shadow tree like /conf. see [1] and [2] for details.


stefan

[1] http://wcm.io/config/api/terminology.html
[2] http://wcm.io/config/api/usage-spi.html


12