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
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
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
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
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
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
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, ClassT type);
for a single and
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,
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
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
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
: [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
...@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
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
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.
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
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
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
[...] 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,
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
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
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
- 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
. 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
...@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
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
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
hello alex.
-Original Message-
From: Alexander Klimetschek [mailto:aklim...@adobe.com]
Sent: Tuesday, October 14, 2014 10:13 PM
To: dev@sling.apache.org
Subject: Re: [PROPOSAL] Context-specific configuration for Apache Sling,
Multitenancy
I see 3 problems:
- allowing to hook in a custom
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
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
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
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
32 matches
Mail list logo
