[jira] [Resolved] (SLING-5406) Optimize configuration change handling

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5406.
-
Resolution: Fixed

I've refactored the change handling in rev 1722178.
Queue configuration changes have no influence anymore as no jobs are reassigned 
etc. therefore I could remove the whole logic for that part.
Property changes are now more lightweight than before as they don't cause the 
job processing to restart.

> Optimize configuration change handling
> --
>
> Key: SLING-5406
> URL: https://issues.apache.org/jira/browse/SLING-5406
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Event 4.1.0
>
>
> There are different kinds of configuration changes:
> - changes in queue configuration
> - topology changes
> Currently these are handled slightly different and can occur concurrently.
> We should unify the code and run it through the same methods. The change 
> detection can be further optimized to ignore irrelevant changes (e.g. new 
> consumers)



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

Re: How to whitelist legit usages of loginAdministrative?

[Marius Petria]

On 12/29/15, 1:24 PM, "Bertrand Delacretaz"  wrote:

>On Tue, Dec 29, 2015 at 11:29 AM, Carsten Ziegeler  
>wrote:
>...
>>>   If "admin safe" mode is enabled, loginAdmin fails *unless* the code
>>>   that calls is is marked with the reason why it's needed.
>>
>> Don't want to be a pita, but that requirement is not in the issue :)..
>
>I said "IMO" ;-)
>
>Anyway we can use this discussion to clarify that requirement, and
>update the ticket later.


I think that is a general problem with service users and it should not be 
solved only for “admin sessions”. We could have a way to express the 
requirements of code, the requirements of an “admin session” is typically 
jcr:all on root and it is a particular example of this requirements language. 
@ServiceRequirement(permission=jcr:all, path=/)


>
>>... Why can't we simply use the same concept as for the service users?
>> The caller bundle needs to be in a list of allowed bundles...
>
>If we accept that the granularity is at the bundle level then yes,
>that would work, the SLING-5135 requirement then becomes
>
>>>   If "admin safe" mode is enabled, loginAdmin fails *unless* it's called 
>>> from
>>>   a bundle that's in the list of allowed bundles.


An alternative way to spin this is to actually deprecate loginAdmin and keep 
the loginService as the only login API for such things. An admin session should 
be obtain via loginService if the service is mapped to “admin” user. We can 
have the white list of bundles and services that are allowed to map to “admin" 
and that can be implemented at validator level. 

Marius

Re: [VOTE] Release Apache Sling Settings 1.3.8

[Daniel Klco]

+1

On Tue, Dec 29, 2015 at 6:33 AM, Bertrand Delacretaz  wrote:

> On Tue, Dec 29, 2015 at 11:21 AM, Carsten Ziegeler 
> wrote:
> > ...Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1390/
> ..
>
> +1 for the release of
> SHA1(org.apache.sling.settings-1.3.8-source-release.zip)=
> 2d6675fd61d88494b9225c2f8b4c685e2f32b6b2
>
> Checked signatures, build and svn tag.
>
> -Bertrand
>

Re: [VOTE] Release org.apache.sling.junit.core 1.0.16

[Daniel Klco]

+1

On Tue, Dec 29, 2015 at 7:23 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release org.apache.sling.junit.teleporter 1.0.6

[Daniel Klco]

+1

On Tue, Dec 29, 2015 at 7:23 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Sling Discovery Standalone 1.0.2

[Daniel Klco]

+1

On Tue, Dec 29, 2015 at 8:49 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[VOTE] Release Apache Sling Parent 26

[Carsten Ziegeler]

Hi,

we solved eight issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333678


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1394/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1394 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Carsten

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

Re: [VOTE] Release Apache Sling Parent 26

[Carsten Ziegeler]

+1


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

[jira] [Commented] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074713#comment-15074713
 ] 

Carsten Ziegeler commented on SLING-4752:
-

Moving new query api to next version

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>  Labels: Sling-9-ReleaseNotes
> Fix For: JCR Resource 2.7.0, API 2.11.0, Resource Resolver 1.4.0
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

[jira] [Updated] (SLING-5221) Implement query provider

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5221:

Fix Version/s: (was: JCR Resource 2.6.0)
   JCR Resource 2.7.0

> Implement query provider 
> -
>
> Key: SLING-5221
> URL: https://issues.apache.org/jira/browse/SLING-5221
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Reporter: Carsten Ziegeler
> Fix For: JCR Resource 2.7.0
>
>
> We should implement the new query provider interface in the JCR implementation



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

[jira] [Commented] (SLING-5221) Implement query provider

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074712#comment-15074712
 ] 

Carsten Ziegeler commented on SLING-5221:
-

Moving new query implementation to next version

> Implement query provider 
> -
>
> Key: SLING-5221
> URL: https://issues.apache.org/jira/browse/SLING-5221
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Reporter: Carsten Ziegeler
> Fix For: JCR Resource 2.7.0
>
>
> We should implement the new query provider interface in the JCR implementation



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

[jira] [Updated] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4752:

Fix Version/s: (was: JCR Resource 2.6.0)
   (was: Resource Resolver 1.3.0)
   (was: API 2.10.0)
   Resource Resolver 1.4.0
   API 2.11.0
   JCR Resource 2.7.0

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>  Labels: Sling-9-ReleaseNotes
> Fix For: JCR Resource 2.7.0, API 2.11.0, Resource Resolver 1.4.0
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

How to whitelist legit usages of loginAdministrative?

[Bertrand Delacretaz]

Hi,

This is about SLING-5135, do people have ideas for identifying which
usages of loginAdministrative are acceptable?

I'll need this for SLING-5355 for example, which creates users and
sets access control.

IMO the proper way to keep track of this is to keep the explanation
why the programmer thinks it's ok to use loginAdministrative in the
code, next to the "get admin session" call.

Here's a suggested pattern that forces the caller to use a specific
wrapper class to get an admin session:

  // This code needs an admin session, for a valid reason
  // which is spelled out in the SlingAdminSession constructor
  Session s = new SlingAdminSession(repository, "setting access
control at Sling startup").getSession();

And we modify the existing loginAdministrative method to fail (when
isDisableLoginAdministrative is true) unless it is called from
SlingAdminSession, detected using
Thread.currentThread().getStackTrace().

This allows for removing all loginAdministrative calls from our code,
and easily checking that with grep.
And also auditing with grep where "new style" admin sessions are used.

We can then use a similar pattern for
ResourceResolverFactory.getAdministrativeResourceResolver(), if we are
still using this deprecated method.

WDYT?

-Bertrand

[jira] [Commented] (SLING-5135) Extend AbstractSlingRepositoryManager to whitelist loginAdministrative usage

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073669#comment-15073669
 ] 

Bertrand Delacretaz commented on SLING-5135:


Note that we'll need a similar mechanism for 
{{ResourceResolverFactory.getAdministrativeResourceResolver()}}. I have 
suggested a mechanism on the Sling dev list in the _How to whitelist legit 
usages of loginAdministrative?_ thread.

> Extend AbstractSlingRepositoryManager to whitelist loginAdministrative usage
> 
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

Re: How to whitelist legit usages of loginAdministrative?

[Carsten Ziegeler]

Hi,

I don't understand what makes grepping for SlingAdminSession easier than
grepping for loginAdministrative?

Carsten

Bertrand Delacretaz wrote
> Hi,
> 
> This is about SLING-5135, do people have ideas for identifying which
> usages of loginAdministrative are acceptable?
> 
> I'll need this for SLING-5355 for example, which creates users and
> sets access control.
> 
> IMO the proper way to keep track of this is to keep the explanation
> why the programmer thinks it's ok to use loginAdministrative in the
> code, next to the "get admin session" call.
> 
> Here's a suggested pattern that forces the caller to use a specific
> wrapper class to get an admin session:
> 
>   // This code needs an admin session, for a valid reason
>   // which is spelled out in the SlingAdminSession constructor
>   Session s = new SlingAdminSession(repository, "setting access
> control at Sling startup").getSession();
> 
> And we modify the existing loginAdministrative method to fail (when
> isDisableLoginAdministrative is true) unless it is called from
> SlingAdminSession, detected using
> Thread.currentThread().getStackTrace().
> 
> This allows for removing all loginAdministrative calls from our code,
> and easily checking that with grep.
> And also auditing with grep where "new style" admin sessions are used.
> 
> We can then use a similar pattern for
> ResourceResolverFactory.getAdministrativeResourceResolver(), if we are
> still using this deprecated method.
> 
> WDYT?
> 
> -Bertrand
> 


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

Re: How to whitelist legit usages of loginAdministrative?

[Bertrand Delacretaz]

Hi,

On Tue, Dec 29, 2015 at 10:10 AM, Carsten Ziegeler  wrote:
> I don't understand what makes grepping for SlingAdminSession easier than
> grepping for loginAdministrative?

Grepping for loginAdministrative returns all existing legacy
occurences, you have no way of knowing of they have been validated as
having good reasons.

Grepping SlingAdminSession returns only calls that have been added
after introducing this SLING-5135 whitelisting mechanism. And its
constructor requires providing a reason for getting an admin session,
so the justification is "local" to the code, no need to search
elsewhere.

-Bertrand

Re: How to whitelist legit usages of loginAdministrative?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> Hi,
> 
> On Tue, Dec 29, 2015 at 10:10 AM, Carsten Ziegeler  
> wrote:
>> I don't understand what makes grepping for SlingAdminSession easier than
>> grepping for loginAdministrative?
> 
> Grepping for loginAdministrative returns all existing legacy
> occurences, you have no way of knowing of they have been validated as
> having good reasons.

Hmm, ok
> 
> Grepping SlingAdminSession returns only calls that have been added
> after introducing this SLING-5135 whitelisting mechanism. And its
> constructor requires providing a reason for getting an admin session,
> so the justification is "local" to the code, no need to search
> elsewhere.
> 
Well, this looks nice, but the reason has no real value, I can put there
"This code needs it", "Workaround" etc. So having this in the API is not
really of value.
But how does SlingAdminSession work? How is it protected from being
called all over the place?

Carsten

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

Re: How to whitelist legit usages of loginAdministrative?

[Carsten Ziegeler]

I think that adding new api in whatever form is not a good idea: this
makes the code unusable with older api versions and binds it to the
latest and greatest repository api/implementation.
Adding a new api because of a tooling problem (simple grep not working)
while breaking compatibility is something we should avoid. If we simply
require a comment on the same line as the loginAdmin (just as an
example) a simple grep works ootb.

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

[jira] [Assigned] (SLING-5135) Extend AbstractSlingRepositoryManager to whitelist loginAdministrative usage

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reassigned SLING-5135:
--

Assignee: Bertrand Delacretaz

> Extend AbstractSlingRepositoryManager to whitelist loginAdministrative usage
> 
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

Re: How to whitelist legit usages of loginAdministrative?

[Bertrand Delacretaz]

On Tue, Dec 29, 2015 at 11:29 AM, Carsten Ziegeler  wrote:
...
>>   If "admin safe" mode is enabled, loginAdmin fails *unless* the code
>>   that calls is is marked with the reason why it's needed.
>
> Don't want to be a pita, but that requirement is not in the issue :)..

I said "IMO" ;-)

Anyway we can use this discussion to clarify that requirement, and
update the ticket later.

>... Why can't we simply use the same concept as for the service users?
> The caller bundle needs to be in a list of allowed bundles...

If we accept that the granularity is at the bundle level then yes,
that would work, the SLING-5135 requirement then becomes

>>   If "admin safe" mode is enabled, loginAdmin fails *unless* it's called from
>>   a bundle that's in the list of allowed bundles.

-Bertrand

[VOTE] Release org.apache.sling.junit.core 1.0.16

[Bertrand Delacretaz]

Hi,

We solved 1 issue in this release:

https://issues.apache.org/jira/browse/SLING/fixforversion/12334311

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1392

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1392 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Here's my +1

-Bertrand

Re: [VOTE] Release org.apache.sling.junit.core 1.0.16

[Carsten Ziegeler]

+1


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

Re: [VOTE] Release Apache Sling Settings 1.3.8

[Bertrand Delacretaz]

On Tue, Dec 29, 2015 at 11:21 AM, Carsten Ziegeler  wrote:
> ...Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1390/..

+1 for the release of
SHA1(org.apache.sling.settings-1.3.8-source-release.zip)=
2d6675fd61d88494b9225c2f8b4c685e2f32b6b2

Checked signatures, build and svn tag.

-Bertrand

Re: [VOTE] Release org.apache.sling.junit.teleporter 1.0.6

[Carsten Ziegeler]

+1


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

Re: How to whitelist legit usages of loginAdministrative?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Tue, Dec 29, 2015 at 11:29 AM, Carsten Ziegeler  
> wrote:
> ...
>>>   If "admin safe" mode is enabled, loginAdmin fails *unless* the code
>>>   that calls is is marked with the reason why it's needed.
>>
>> Don't want to be a pita, but that requirement is not in the issue :)..
> 
> I said "IMO" ;-)

:)

> 
>> ... Why can't we simply use the same concept as for the service users?
>> The caller bundle needs to be in a list of allowed bundles...
> 
> If we accept that the granularity is at the bundle level then yes,
> that would work, the SLING-5135 requirement then becomes
> 

I think that's easy and sufficient. A bundle doesn't get more insecure
whether it
is doing a single loginAdmin call or several (of course the danger of
wrong code
is higher) - if you have one open door it doesn't matter if you have
more open doors or not.

For legitimate usages we can require a comment similar to Sonar's //
NOSONAR on the same line.

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

[VOTE] Release Apache Sling Discovery Standalone 1.0.2

[Carsten Ziegeler]

Hi,

we solved one issue
https://issues.apache.org/jira/browse/SLING-5405


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1393/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1393 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Carsten

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

Re: [VOTE] Release Apache Sling Discovery Standalone 1.0.2

[Carsten Ziegeler]

+1


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

[VOTE] Release org.apache.sling.junit.teleporter 1.0.6

[Bertrand Delacretaz]

Hi,

We solved 2 issues in this release:

https://issues.apache.org/jira/browse/SLING/fixforversion/12334312

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1391

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1391/tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Here's my +1.

-Bertrand

[jira] [Resolved] (SLING-5405) TopologyView contract is not correctly followed on property changes

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5405.
-
Resolution: Fixed

Creating a new view on each change now, invalidating old views.
Added a bunch of tests to verify the behaviour

> TopologyView contract is not correctly followed on property changes
> ---
>
> Key: SLING-5405
> URL: https://issues.apache.org/jira/browse/SLING-5405
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Standalone 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Discovery Standalone 1.0.2
>
>
> When properties change, a properties change event is sent out, however no new 
> view object is created, instead the old view object is altered.
> This is against the contract of topology view as it should be immutable once 
> sent out.



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

[jira] [Created] (SLING-5406) Optimize configuration change handling

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5406:
---

 Summary: Optimize configuration change handling
 Key: SLING-5406
 URL: https://issues.apache.org/jira/browse/SLING-5406
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Event 4.1.0


There are different kinds of configuration changes:
- changes in queue configuration
- topology changes
Currently these are handled slightly different and can occur concurrently.

We should unify the code and run it through the same methods. The change 
detection can be further optimized to ignore irrelevant changes (e.g. new 
consumers)



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

Re: How to whitelist legit usages of loginAdministrative?

[Bertrand Delacretaz]

On Tue, Dec 29, 2015 at 10:43 AM, Carsten Ziegeler  wrote:
> ...If we simply
> require a comment on the same line as the loginAdmin (just as an
> example) a simple grep works ootb

That's not sufficient, IMO the SLING-5135 requirement is:

  If "admin safe" mode is enabled, loginAdmin fails *unless* the code
  that calls is is marked with the reason why it's needed.

An inline comment works for static code analysis but cannot cause
existing code to fail, which we want.

You have a good point about keeping the code compatible with older
modules - if we don't want any API changes we might use a method
annotation to indicate the reason:

  @RequiresLoginAdmin("setting ACL at startup")
  void doSometing() {
Session s = repository.loginAdministrative()
  }

We'd need to go up the stack trace to grab the annotation in the
loginAdmin code, but as we require the direct caller to have the
annotation it shouldn't be too costly.

WDYT?

-Bertrand

Re: How to whitelist legit usages of loginAdministrative?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Tue, Dec 29, 2015 at 10:43 AM, Carsten Ziegeler  
> wrote:
>> ...If we simply
>> require a comment on the same line as the loginAdmin (just as an
>> example) a simple grep works ootb
> 
> That's not sufficient, IMO the SLING-5135 requirement is:
> 
>   If "admin safe" mode is enabled, loginAdmin fails *unless* the code
>   that calls is is marked with the reason why it's needed.

Don't want to be a pita, but that requirement is not in the issue :)
Who has the control of what is allowed and what is not?
Is it the caller? then yes it must provide a good reason.
Is it the called service? Then how can it check the reason for being a
good reason?
We should clarify that question first.


Why can't we simply use the same concept as for the service users?
The caller bundle needs to be in a list of allowed bundles.

PS: The below approach adds new api (an annotation) as well :)

Regards
Carsten

> 
> An inline comment works for static code analysis but cannot cause
> existing code to fail, which we want.
> 
> You have a good point about keeping the code compatible with older
> modules - if we don't want any API changes we might use a method
> annotation to indicate the reason:
> 
>   @RequiresLoginAdmin("setting ACL at startup")
>   void doSometing() {
> Session s = repository.loginAdministrative()
>   }
> 
> We'd need to go up the stack trace to grab the annotation in the
> loginAdmin code, but as we require the direct caller to have the
> annotation it shouldn't be too costly.
> 
> WDYT?
> 
> -Bertrand
> 


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

[jira] [Created] (SLING-5405) TopologyView contract is not correctly followed on property changes

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5405:
---

 Summary: TopologyView contract is not correctly followed on 
property changes
 Key: SLING-5405
 URL: https://issues.apache.org/jira/browse/SLING-5405
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Standalone 1.0.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Discovery Standalone 1.0.2


When properties change, a properties change event is sent out, however no new 
view object is created, instead the old view object is altered.
This is against the contract of topology view as it should be immutable once 
sent out.



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

[VOTE] Release Apache Sling Settings 1.3.8

[Carsten Ziegeler]

Hi,

we solved two issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12329660


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1390/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1390 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

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

Re: [VOTE] Release Apache Sling Settings 1.3.8

[Carsten Ziegeler]

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