date:20141015

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

2014-10-15 Thread 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
cziege...@apache.org

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

2014-10-15 Thread Stefan Seifert

hello justin.

i understand you concerns and see what you are pointing at. i hit the problem 
as well at the same time wanting to have single valuemap with all parameters 
and application separation or parameter names. i'm open to removing the 
parameter stuff from the main API, it can always added as a layer on-top.

but carsten introduced a new idea, lets discuss this first.

stefan


-Original Message-
From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
Justin Edelson
Sent: Wednesday, October 15, 2014 2:50 AM
To: dev@sling.apache.org
Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
Multitenancy

Hi Stefan,
To me, this sounds a bit schizophrenic - you're saying that the
preferred way is to use a Parameter object, but that we need to
support String-based lookup. And I'm not actually sure what which
type belongs to which string constant actually means.

Above all, this seems to create a confusing API. Since the expectation
is that String-based lookups will work consistently, there's
effectively no way to use the extra data within the Parameter object
inside the lookup mechanism. For example, you mentioned the idea of
using the application ID from the Parameter object as a way of
expressing scope. But of course, this can't actually happen because
there would be no way to do this with just Strings.

I also personally find the setting of the default at the Parameter
level a bit confusing. IME, defaults are *very* context-sensitive,
whereas (if I understand) the Parameter objects are meant to be used
across-contexts.

All of which is to say that I would rather see the API have a clean
separation between configuration lookup (which can be done purely with
Strings) and Parameter definition. Or, to put in AEM terms, separate
the functionality common to author  publish (configuration lookup)
from the author-side functionality (parameter defintion which leads to
editing).

At this point, Configuration just becomes MapString, ValueMap. The
keys are are the application IDs and the resulting maps are the actual
configurations for that application (which frankly I'd rather see
called 'component' but that's neither here nor there). The only
deviation I'd suggest from normal Map behavior is that
config.get(non-existing-application-id) should return an empty
ValueMap. This would allow you to do null-safe chaining, e.g.
config.get(foo).get(bar) could return null, but never throw an NPE
(unless config itself is null)

If developers choose to adopt the Parameter objects, that's fine.
Perhaps we even should have a utility method
ConfigurationUtils.get(config, param) which calls
config.get(param.getApplicationId()).get(param.getName(),
param.getType()) But this is an optional step and the use of Parameter
objects isn't implied by the Configuration API.

Regards,
Justin

On Tue, Oct 14, 2014 at 6:58 PM, Stefan Seifert sseif...@pro-vision.de
wrote:
 hello justin.

 yes, this is my expectation for the java code. if you only provide a string-
based access to configuration parameter every developer will start to create a
NameConstants class to define the much-used property names (or you will
provide such a class as part of your applications API). then the developer has
to remember which type belongs to which string constant. then you have to find
a way where you define the default values of a parameter, and describe its
edit mode capabilities. all this is covered by building a structured parameter
definition. but yes, it started as a simple helper class with constants to
easy access all existing parameters of an application.

 as a bonus there is an abstract implementation of the ParameterProvider
interface which just reads the static fields of such a class and provides the
defined parameters as OSGi service to the config infrastructure.

 you still need the string-based (or map-based) access for usecases like
sightly templates where it is not so easy or uncommon to use constants for
accessing map values. but in our experience the parameters are used in most
cases in the java business logic behind the presentation layer, not in the
presentation layer (scripts) itself. and of course the lazy developers can use
this access at well in java code...

 stefan


-Original Message-
From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
Justin Edelson
Sent: Tuesday, October 14, 2014 11:32 PM
To: dev@sling.apache.org
Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
Multitenancy

Hi Stefan,
Thanks for clarifying. So is it accurate to say that your expectation
that the *vast* majority of clients to use a strongly-typed Parameter
object rather than doing a simple String lookup?

To me, this seems very heavyweight, but maybe I am being short sighted
(or lazy).

But on the other hand, if you expect clients to use Paramter objects,
why support String lookup at all?

Justin

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

2014-10-15 Thread 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.

do you have a link where such a concept is defined in context of the new DS 
specification? using the same concept as a (new) DS version would be plus.

wouldn't it be an option to use a plain interface with default values as 
annotations? this comes close to what sling models supports today.

my statement about support only types from JCR was not precise - i meant 
support all primitive types including string array plus map, but no custom or 
more advanced objects, because this would make things really complicated. 
currently a subset of primitive types is supported [1].

stefan

[1] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions




-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: Wednesday, October 15, 2014 8:24 AM
To: dev@sling.apache.org
Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
Multitenancy

In general, using typed objects is the preferred way to go, so I think a
configuration object should be a type object and return configuration
values in the correct type. Let's not fall back into the 80s and fiddle
around with string conversions all over the place.
Having a type for a configuration removes also the need for those ugly
name constants and we could hopefully also get away with having ugly
constants for default values.

So what about using the approach we use in the new Declarative Service
specification and you define a configuration as an annotation:

public @interface MyConfiguration {

   int port() default 465;

   String host() default localhost;

   String userId;
}

This leaves us with a single place to define a type configuration object
in combination with default values. We then define simple mapping rules
from names to resource names.

And we should also support *all* java types not just those JCR supports.
Internally all numbers can be stored as long but the configuration
object gives you an integer, char whatever.

This is how I would like to deal with configurations in code.

Carsten

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Updated] (SLING-3899) Access content for replication on behalf of the user that triggered the replication

2014-10-15 Thread Marius Petria (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marius Petria updated SLING-3899:
-
Attachment: SLING-3899.1.diff

I just realized that packages were build with the calling user session. The 
user session should be used only to check privileges, but the actual content 
buliding should be done with the agent session.

 Access content for replication on behalf of the user that triggered the 
 replication
 ---

 Key: SLING-3899
 URL: https://issues.apache.org/jira/browse/SLING-3899
 Project: Sling
  Issue Type: Improvement
  Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
 Attachments: SLING-3899.1.diff, SLING-3899.diff


 Currently the content is accessed via an administrative session. We need to 
 pass a ResourceResolver via all APIs to ensure that the content is accessed 
 only be users that have the right.
 For rule triggered requests the actions should be done on the behalf of a 
 replication-service-user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4049) Errorhandling: Allow Configuration of Displaying Stacktraces/Request Progress

2014-10-15 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SLING-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172086#comment-14172086
 ] 

Dominique Jäggi commented on SLING-4049:


{quote}The error handling system is configurable and I would think that for a 
production setup custom errorhandler scripts should be created which don't 
expose stacktraces, request progress trackers, and system version.{quote}

i don't think a production customer would understand the need to deploy custom 
code simply to turn off insecure stack traces / request progress. this sounds 
like wanting to evade the (rather minimal) effort of making this configurable.

 Errorhandling: Allow Configuration of Displaying Stacktraces/Request Progress
 -

 Key: SLING-4049
 URL: https://issues.apache.org/jira/browse/SLING-4049
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Dominique Jäggi

 it should be configurable whether during error display (40x, 50x, etc) 
 stacktraces or the request progress is displayed or not. 
 for production systems it is undesirable to exhibit information that may 
 allow an attacker to determine internal information such as used scripts, 
 paths, classes, line numbers, etc.
 ideally this could be centrally configured, affecting both e.g. the JSP 
 handlers (404.jsp) as well as any other facility outputting error conditions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-3899) Access content for replication on behalf of the user that triggered the replication

2014-10-15 Thread Tommaso Teofili (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reopened SLING-3899:


 Access content for replication on behalf of the user that triggered the 
 replication
 ---

 Key: SLING-3899
 URL: https://issues.apache.org/jira/browse/SLING-3899
 Project: Sling
  Issue Type: Improvement
  Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
 Attachments: SLING-3899.1.diff, SLING-3899.diff


 Currently the content is accessed via an administrative session. We need to 
 pass a ResourceResolver via all APIs to ensure that the content is accessed 
 only be users that have the right.
 For rule triggered requests the actions should be done on the behalf of a 
 replication-service-user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4051) Warning about unset VLT package version when using Sling replication

2014-10-15 Thread Tommaso Teofili (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated SLING-4051:
---
Summary: Warning about unset VLT package version when using Sling 
replication  (was: Warning about unset version when using replication.next)

 Warning about unset VLT package version when using Sling replication
 

 Key: SLING-4051
 URL: https://issues.apache.org/jira/browse/SLING-4051
 Project: Sling
  Issue Type: Bug
  Components: Replication
Reporter: Laurie byrum

 I use the following code to replicate:
 @Reference(target = (name=blah-reverse), policy = 
 ReferencePolicy.DYNAMIC,
 cardinality = ReferenceCardinality.OPTIONAL_UNARY)
 ReplicationAgent replicationAgent;
 private void reverseReplicate(String path) throws 
 AgentReplicationException {
 if (replicationAgent != null) {
 ReplicationRequest replicationRequest = new ReplicationRequest(0, 
 ReplicationActionType.ADD, path);
 replicationAgent.execute(replicationRequest);
 }
 }
 I get the following warning in my log when that happens: 
 14.10.2014 14:13:54.544 *WARN* [0:0:0:0:0:0:0:1 [1413321186378] POST blah 
 HTTP/1.1] org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl 
 Package does not specify a version. setting to ''



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-4051) Warning about unset VLT package version when using Sling replication

2014-10-15 Thread Tommaso Teofili (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-4051:
--

Assignee: Tommaso Teofili

 Warning about unset VLT package version when using Sling replication
 

 Key: SLING-4051
 URL: https://issues.apache.org/jira/browse/SLING-4051
 Project: Sling
  Issue Type: Bug
  Components: Replication
Reporter: Laurie byrum
Assignee: Tommaso Teofili

 I use the following code to replicate:
 @Reference(target = (name=blah-reverse), policy = 
 ReferencePolicy.DYNAMIC,
 cardinality = ReferenceCardinality.OPTIONAL_UNARY)
 ReplicationAgent replicationAgent;
 private void reverseReplicate(String path) throws 
 AgentReplicationException {
 if (replicationAgent != null) {
 ReplicationRequest replicationRequest = new ReplicationRequest(0, 
 ReplicationActionType.ADD, path);
 replicationAgent.execute(replicationRequest);
 }
 }
 I get the following warning in my log when that happens: 
 14.10.2014 14:13:54.544 *WARN* [0:0:0:0:0:0:0:1 [1413321186378] POST blah 
 HTTP/1.1] org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl 
 Package does not specify a version. setting to ''



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4051) Warning about unset VLT package version when using Sling replication

2014-10-15 Thread Tommaso Teofili (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172092#comment-14172092
 ] 

Tommaso Teofili commented on SLING-4051:


thanks Laurie for reporting this!

 Warning about unset VLT package version when using Sling replication
 

 Key: SLING-4051
 URL: https://issues.apache.org/jira/browse/SLING-4051
 Project: Sling
  Issue Type: Bug
  Components: Replication
Reporter: Laurie byrum

 I use the following code to replicate:
 @Reference(target = (name=blah-reverse), policy = 
 ReferencePolicy.DYNAMIC,
 cardinality = ReferenceCardinality.OPTIONAL_UNARY)
 ReplicationAgent replicationAgent;
 private void reverseReplicate(String path) throws 
 AgentReplicationException {
 if (replicationAgent != null) {
 ReplicationRequest replicationRequest = new ReplicationRequest(0, 
 ReplicationActionType.ADD, path);
 replicationAgent.execute(replicationRequest);
 }
 }
 I get the following warning in my log when that happens: 
 14.10.2014 14:13:54.544 *WARN* [0:0:0:0:0:0:0:1 [1413321186378] POST blah 
 HTTP/1.1] org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl 
 Package does not specify a version. setting to ''



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-3899) Access content for replication on behalf of the user that triggered the replication

2014-10-15 Thread Marius Petria (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marius Petria updated SLING-3899:
-
Attachment: SLING-3899.2.diff

 Access content for replication on behalf of the user that triggered the 
 replication
 ---

 Key: SLING-3899
 URL: https://issues.apache.org/jira/browse/SLING-3899
 Project: Sling
  Issue Type: Improvement
  Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
 Attachments: SLING-3899.1.diff, SLING-3899.2.diff, SLING-3899.diff


 Currently the content is accessed via an administrative session. We need to 
 pass a ResourceResolver via all APIs to ensure that the content is accessed 
 only be users that have the right.
 For rule triggered requests the actions should be done on the behalf of a 
 replication-service-user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-3899) Access content for replication on behalf of the user that triggered the replication

2014-10-15 Thread Marius Petria (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marius Petria updated SLING-3899:
-
Attachment: SLING-3899.3.diff

 Access content for replication on behalf of the user that triggered the 
 replication
 ---

 Key: SLING-3899
 URL: https://issues.apache.org/jira/browse/SLING-3899
 Project: Sling
  Issue Type: Improvement
  Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
 Attachments: SLING-3899.1.diff, SLING-3899.2.diff, SLING-3899.3.diff, 
 SLING-3899.diff


 Currently the content is accessed via an administrative session. We need to 
 pass a ResourceResolver via all APIs to ensure that the content is accessed 
 only be users that have the right.
 For rule triggered requests the actions should be done on the behalf of a 
 replication-service-user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-3899) Access content for replication on behalf of the user that triggered the replication

2014-10-15 Thread Tommaso Teofili (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved SLING-3899.

Resolution: Fixed

thanks again Marius, I've applied your latest patch in r1631965

 Access content for replication on behalf of the user that triggered the 
 replication
 ---

 Key: SLING-3899
 URL: https://issues.apache.org/jira/browse/SLING-3899
 Project: Sling
  Issue Type: Improvement
  Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
 Attachments: SLING-3899.1.diff, SLING-3899.2.diff, SLING-3899.3.diff, 
 SLING-3899.diff


 Currently the content is accessed via an administrative session. We need to 
 pass a ResourceResolver via all APIs to ensure that the content is accessed 
 only be users that have the right.
 For rule triggered requests the actions should be done on the behalf of a 
 replication-service-user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

2014-10-15 Thread 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:cziege...@apache.org] Sent: Wednesday, October 15, 2014
8:24 AM To: dev@sling.apache.org Subject: Re: FW: [PROPOSAL]
Context-specific configuration for Apache Sling, Multitenancy

In general, using typed objects is the preferred way to go, so I
think a configuration object should be a type object and return
configuration values in the correct type. Let's not fall back into
the 80s and fiddle around with string conversions all over the
place. Having a type for a configuration removes also the need for
those ugly name constants and we could hopefully also get away with
having ugly constants for default values.

So what about using the approach we use in the new Declarative
Service specification and you define a configuration as an
annotation:

public @interface MyConfiguration {

int port() default 465;

String host() default localhost;

String userId; }

This leaves us with a single place to define a type configuration
object in combination with default values. We then define simple
mapping rules from names to resource names.

And we should also support *all* java types not just those JCR
supports. Internally all numbers can be stored as long but the
configuration object gives you an integer, char whatever.

This is how I would like to deal with configurations in code.

Carsten

-- Carsten Ziegeler Adobe Research Switzerland
cziege...@apache.org

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

83 matches

Mail list logo