RE: Time for a Sling Validation 1.0.0 release

2017-03-06 Thread Stefan Seifert
when this three classes are not intended to be derived from we should 
definitely declare them final to be on the safe side.

stefan


>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Monday, March 6, 2017 8:09 PM
>To: dev@sling.apache.org
>Subject: Re: Time for a Sling Validation 1.0.0 release
>
>Hi Stefan, thanks for your comments.
>IIRC the provider and consumer type annotations only have an influence if
>you derive from/implement those.
>I would for now be in favor of making all those final (i.e. prevent to
>derive from those classes). If there really is a need to implement your own
>ValidationFailure or ValidationResult you should rather start from scratch.
>
>WDYT?
>Konrad
>
>> Am 06.03.2017 um 19:06 schrieb Stefan Seifert :
>>
>> i did not had the time to really think into the API itself, but from a
>formal perspective I think for those 3 classes it would be good to
>explicitly add the corresponding @ProviderType or @ConsumerType annotation:
>>
>> org.apache.sling.validation.SlingValidationException -> @ProviderType,
>and maybe make it final?
>> org.apache.sling.validation.spi.DefaultValidationFailure -> @ConsumerType
>?
>> org.apache.sling.validation.spi.DefaultValidationResult -> @ConsumerType
>?
>>
>> stefan
>>
>>
>>> -Original Message-
>>> From: Konrad Windszus [mailto:konra...@gmx.de]
>>> Sent: Wednesday, March 1, 2017 9:03 AM
>>> To: dev@sling.apache.org
>>> Subject: Time for a Sling Validation 1.0.0 release
>>>
>>> Hi everyone,
>>> I think it is time now for a first release of Sling Validation. I used
>it
>>> in several projects already productively and fixed a lot of bugs and
>>> refactored the interfaces from the initial proposal from Radu quite a
>bit
>>> (44 issues have been resolved since then,
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980).
>>> It would be good if everyone who could afford some time could quickly
>>> cross-check the API at
>>>
>https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/ap
>>> i.
>>> All concerns being raised in a previous review
>>> (https://issues.apache.org/jira/browse/SLING-4027) have been addressed
>>> meanwhile.
>>>
>>> Thanks,
>>> Konrad
>>>
>>
>>
>




[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Felix Meschberger (JIRA)

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

Felix Meschberger commented on SLING-6609:
--

Thanks, [~kwin]. Looks good except, I'd defer to {{get(String)}} instead of 
{{get(String, Class)}} as with the {{defaultValue}} being {{null}} we don't 
know the desired type and would have to assume {{Object}}, hence no conversion.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Time for a Sling Validation 1.0.0 release

2017-03-06 Thread Konrad Windszus
Actually thinking about this further:

DefaultValidationFailure implements already a ProviderType (namely 
ValidationFailure). That should make that class inherit the ProviderType 
annotation as well. I Have not verified that with bnd (baselining as well as 
import-packages) though.

> Am 06.03.2017 um 20:09 schrieb Konrad Windszus :
> 
> Hi Stefan, thanks for your comments.
> IIRC the provider and consumer type annotations only have an influence if you 
> derive from/implement those.
> I would for now be in favor of making all those final (i.e. prevent to derive 
> from those classes). If there really is a need to implement your own 
> ValidationFailure or ValidationResult you should rather start from scratch.
> 
> WDYT?
> Konrad
> 
>> Am 06.03.2017 um 19:06 schrieb Stefan Seifert :
>> 
>> i did not had the time to really think into the API itself, but from a 
>> formal perspective I think for those 3 classes it would be good to 
>> explicitly add the corresponding @ProviderType or @ConsumerType annotation:
>> 
>> org.apache.sling.validation.SlingValidationException -> @ProviderType, and 
>> maybe make it final?
>> org.apache.sling.validation.spi.DefaultValidationFailure -> @ConsumerType ?
>> org.apache.sling.validation.spi.DefaultValidationResult -> @ConsumerType ?
>> 
>> stefan
>> 
>> 
>>> -Original Message-
>>> From: Konrad Windszus [mailto:konra...@gmx.de]
>>> Sent: Wednesday, March 1, 2017 9:03 AM
>>> To: dev@sling.apache.org
>>> Subject: Time for a Sling Validation 1.0.0 release
>>> 
>>> Hi everyone,
>>> I think it is time now for a first release of Sling Validation. I used it
>>> in several projects already productively and fixed a lot of bugs and
>>> refactored the interfaces from the initial proposal from Radu quite a bit
>>> (44 issues have been resolved since then,
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980).
>>> It would be good if everyone who could afford some time could quickly
>>> cross-check the API at
>>> https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/ap
>>> i.
>>> All concerns being raised in a previous review
>>> (https://issues.apache.org/jira/browse/SLING-4027) have been addressed
>>> meanwhile.
>>> 
>>> Thanks,
>>> Konrad
>>> 
>> 
>> 
> 



Re: Time for a Sling Validation 1.0.0 release

2017-03-06 Thread Konrad Windszus
Hi Stefan, thanks for your comments.
IIRC the provider and consumer type annotations only have an influence if you 
derive from/implement those.
I would for now be in favor of making all those final (i.e. prevent to derive 
from those classes). If there really is a need to implement your own 
ValidationFailure or ValidationResult you should rather start from scratch.

WDYT?
Konrad

> Am 06.03.2017 um 19:06 schrieb Stefan Seifert :
> 
> i did not had the time to really think into the API itself, but from a formal 
> perspective I think for those 3 classes it would be good to explicitly add 
> the corresponding @ProviderType or @ConsumerType annotation:
> 
> org.apache.sling.validation.SlingValidationException -> @ProviderType, and 
> maybe make it final?
> org.apache.sling.validation.spi.DefaultValidationFailure -> @ConsumerType ?
> org.apache.sling.validation.spi.DefaultValidationResult -> @ConsumerType ?
> 
> stefan
> 
> 
>> -Original Message-
>> From: Konrad Windszus [mailto:konra...@gmx.de]
>> Sent: Wednesday, March 1, 2017 9:03 AM
>> To: dev@sling.apache.org
>> Subject: Time for a Sling Validation 1.0.0 release
>> 
>> Hi everyone,
>> I think it is time now for a first release of Sling Validation. I used it
>> in several projects already productively and fixed a lot of bugs and
>> refactored the interfaces from the initial proposal from Radu quite a bit
>> (44 issues have been resolved since then,
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980).
>> It would be good if everyone who could afford some time could quickly
>> cross-check the API at
>> https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/ap
>> i.
>> All concerns being raised in a previous review
>> (https://issues.apache.org/jira/browse/SLING-4027) have been addressed
>> meanwhile.
>> 
>> Thanks,
>> Konrad
>> 
> 
> 



RE: Time for a Sling Validation 1.0.0 release

2017-03-06 Thread Stefan Seifert
i did not had the time to really think into the API itself, but from a formal 
perspective I think for those 3 classes it would be good to explicitly add the 
corresponding @ProviderType or @ConsumerType annotation:

org.apache.sling.validation.SlingValidationException -> @ProviderType, and 
maybe make it final?
org.apache.sling.validation.spi.DefaultValidationFailure -> @ConsumerType ?
org.apache.sling.validation.spi.DefaultValidationResult -> @ConsumerType ?

stefan


>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Wednesday, March 1, 2017 9:03 AM
>To: dev@sling.apache.org
>Subject: Time for a Sling Validation 1.0.0 release
>
>Hi everyone,
>I think it is time now for a first release of Sling Validation. I used it
>in several projects already productively and fixed a lot of bugs and
>refactored the interfaces from the initial proposal from Radu quite a bit
>(44 issues have been resolved since then,
>https://issues.apache.org/jira/browse/SLING/fixforversion/12328980).
>It would be good if everyone who could afford some time could quickly
>cross-check the API at
>https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/ap
>i.
>All concerns being raised in a previous review
>(https://issues.apache.org/jira/browse/SLING-4027) have been addressed
>meanwhile.
>
>Thanks,
>Konrad
>




RE: [VOTE] Release Apache Sling Distributed Event Admin 1.1.2

2017-03-06 Thread Stefan Seifert
+1




[jira] [Commented] (SLING-6614) JcrContentLoader should ignore protected nodes and properties

2017-03-06 Thread Guillaume Lucazeau (JIRA)

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

Guillaume Lucazeau commented on SLING-6614:
---

PR: https://github.com/apache/sling/pull/201

> JcrContentLoader should ignore protected nodes and properties
> -
>
> Key: SLING-6614
> URL: https://issues.apache.org/jira/browse/SLING-6614
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Guillaume Lucazeau
>
> When exporting node tree from Sling as JSON, it would be nice to be able to 
> import it directly into another path or JCR repository.
> Currently, this is not possible as the export contains protected properties 
> ("jcr:created") and protected nodes (ACLs).
> The content loader should ignore them and process the other content.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Issue Comment Deleted] (SLING-6614) JcrContentLoader should ignore protected nodes and properties

2017-03-06 Thread Guillaume Lucazeau (JIRA)

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

Guillaume Lucazeau updated SLING-6614:
--
Comment: was deleted

(was: PR: https://github.com/apache/sling/pull/201)

> JcrContentLoader should ignore protected nodes and properties
> -
>
> Key: SLING-6614
> URL: https://issues.apache.org/jira/browse/SLING-6614
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Guillaume Lucazeau
>
> When exporting node tree from Sling as JSON, it would be nice to be able to 
> import it directly into another path or JCR repository.
> Currently, this is not possible as the export contains protected properties 
> ("jcr:created") and protected nodes (ACLs).
> The content loader should ignore them and process the other content.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6614) JcrContentLoader should ignore protected nodes and properties

2017-03-06 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on SLING-6614:
---

GitHub user glucazeau opened a pull request:

https://github.com/apache/sling/pull/201

SLING-6614: check that property/parent node is not protected before import



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/glucazeau/sling dev

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/201.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #201


commit 08145afef696c2874eac9a94cc0bf0f7f2b5a0f1
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:53:33Z

Check if property is protected before creation

SLING-6614

commit 0821ce18328e0557eb0f05a908b7abaceb2803c2
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:54:44Z

Fix existing unit tests

SLING-6614

commit 90cab96bec0e7efe2877f8f366c1391afc511b14
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:57:13Z

Add createProtectedProperty unit test

SLING-6614

commit eb77aeebe45fbca408d42cd86ea1a01e1cd6efa8
Author: Guillaume Lucazeau 
Date:   2017-03-06T16:07:13Z

Add unit test for node creation under protected node

SLING-6614

commit d03f1afd6a08ca664feceae5cf45f1203d2c869e
Author: Guillaume Lucazeau 
Date:   2017-03-06T16:07:59Z

Check parent node is not protected before creating node

SLING-6614




> JcrContentLoader should ignore protected nodes and properties
> -
>
> Key: SLING-6614
> URL: https://issues.apache.org/jira/browse/SLING-6614
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Guillaume Lucazeau
>
> When exporting node tree from Sling as JSON, it would be nice to be able to 
> import it directly into another path or JCR repository.
> Currently, this is not possible as the export contains protected properties 
> ("jcr:created") and protected nodes (ACLs).
> The content loader should ignore them and process the other content.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] sling pull request #201: SLING-6614: check that property/parent node is not ...

2017-03-06 Thread glucazeau
GitHub user glucazeau opened a pull request:

https://github.com/apache/sling/pull/201

SLING-6614: check that property/parent node is not protected before import



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/glucazeau/sling dev

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/201.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #201


commit 08145afef696c2874eac9a94cc0bf0f7f2b5a0f1
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:53:33Z

Check if property is protected before creation

SLING-6614

commit 0821ce18328e0557eb0f05a908b7abaceb2803c2
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:54:44Z

Fix existing unit tests

SLING-6614

commit 90cab96bec0e7efe2877f8f366c1391afc511b14
Author: Guillaume Lucazeau 
Date:   2017-03-06T14:57:13Z

Add createProtectedProperty unit test

SLING-6614

commit eb77aeebe45fbca408d42cd86ea1a01e1cd6efa8
Author: Guillaume Lucazeau 
Date:   2017-03-06T16:07:13Z

Add unit test for node creation under protected node

SLING-6614

commit d03f1afd6a08ca664feceae5cf45f1203d2c869e
Author: Guillaume Lucazeau 
Date:   2017-03-06T16:07:59Z

Check parent node is not protected before creating node

SLING-6614




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Comment Edited] (SLING-6615) sling listener crashes - cannot reliably start sling

2017-03-06 Thread Andrea Biardi (JIRA)

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

Andrea Biardi edited comment on SLING-6615 at 3/6/17 4:26 PM:
--

attached "log2": log containing thread dump obtained with kill -3


was (Author: shenick_ab):
log containing thread dump obtained with kill -3

> sling listener crashes - cannot reliably start sling
> 
>
> Key: SLING-6615
> URL: https://issues.apache.org/jira/browse/SLING-6615
> Project: Sling
>  Issue Type: Bug
> Environment: linux (centos 5.x / fedora 22)
> java 8 update 111
>Reporter: Andrea Biardi
> Attachments: log, log2, sling_test.sh
>
>
> In my production environment I use a script to upload contents to an instance 
> of sling. Occasionally, I get "Connection refused" errors (I use curl for the 
> uploads).
> Thinking of a problem with my own customizations, I wrote a shell script from 
> scratch, using the discover-sling-in-15-minutes webpage as a reference. I'm 
> attaching the script for reference (careful: it will kill any existing 
> sling.launchpad process).
> I may be doing something wrong here, but this is what I notice:
> - During startup, sling produces a lot of spurious http errors (401,403,503); 
> I believe this is expected, as sling is still booting up.
> - When I'm finally able to upload some content, and I try to retrieve it 
> back, I seem to hit some kind of race condition that shuts down the listener 
> process.
> The crash doesn't happen every time, but still fairly often (say 1 out of 5 
> or 10 runs). When it does, I can see that netstat reports no processes 
> listening on port 8080, although the java PID is still alive. Seems like the 
> listener has crashed, and I have to kill the PID and restart sling.
> Attached is a log of the output from a problematic run (./sling_test 2>&1 | 
> tee log); as you can see towards the end of the file, the loop is stuck in a 
> "Connection refused" error that will never recover.
> At the prompt, I can verify that the sling.launchpad process is still 
> running, however it's no longer listening on port 8080:
> [root@ sl8]# ps axf | grep launchpad
>  3486 pts/0S+ 0:00  \_ grep --color=auto launchpad
>  3076 pts/0Sl 0:21 java -jar org.apache.sling.launchpad-8.jar
> [root@ sl8]# cat /proc/3076/cmdline
> java-jarorg.apache.sling.launchpad-8.jar
> [root@ sl8]# netstat -lnp | grep 8080
> [root@ sl8]#
> Am I doing something wrong or is this a known issue and if so - is there a 
> workaround?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6615) sling listener crashes - cannot reliably start sling

2017-03-06 Thread Andrea Biardi (JIRA)

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

Andrea Biardi updated SLING-6615:
-
Attachment: log2

log containing thread dump obtained with kill -3

> sling listener crashes - cannot reliably start sling
> 
>
> Key: SLING-6615
> URL: https://issues.apache.org/jira/browse/SLING-6615
> Project: Sling
>  Issue Type: Bug
> Environment: linux (centos 5.x / fedora 22)
> java 8 update 111
>Reporter: Andrea Biardi
> Attachments: log, log2, sling_test.sh
>
>
> In my production environment I use a script to upload contents to an instance 
> of sling. Occasionally, I get "Connection refused" errors (I use curl for the 
> uploads).
> Thinking of a problem with my own customizations, I wrote a shell script from 
> scratch, using the discover-sling-in-15-minutes webpage as a reference. I'm 
> attaching the script for reference (careful: it will kill any existing 
> sling.launchpad process).
> I may be doing something wrong here, but this is what I notice:
> - During startup, sling produces a lot of spurious http errors (401,403,503); 
> I believe this is expected, as sling is still booting up.
> - When I'm finally able to upload some content, and I try to retrieve it 
> back, I seem to hit some kind of race condition that shuts down the listener 
> process.
> The crash doesn't happen every time, but still fairly often (say 1 out of 5 
> or 10 runs). When it does, I can see that netstat reports no processes 
> listening on port 8080, although the java PID is still alive. Seems like the 
> listener has crashed, and I have to kill the PID and restart sling.
> Attached is a log of the output from a problematic run (./sling_test 2>&1 | 
> tee log); as you can see towards the end of the file, the loop is stuck in a 
> "Connection refused" error that will never recover.
> At the prompt, I can verify that the sling.launchpad process is still 
> running, however it's no longer listening on port 8080:
> [root@ sl8]# ps axf | grep launchpad
>  3486 pts/0S+ 0:00  \_ grep --color=auto launchpad
>  3076 pts/0Sl 0:21 java -jar org.apache.sling.launchpad-8.jar
> [root@ sl8]# cat /proc/3076/cmdline
> java-jarorg.apache.sling.launchpad-8.jar
> [root@ sl8]# netstat -lnp | grep 8080
> [root@ sl8]#
> Am I doing something wrong or is this a known issue and if so - is there a 
> workaround?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6615) sling listener crashes - cannot reliably start sling

2017-03-06 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-6615:


Can you take a thread dump of the process and attach it here, together with the 
error.log file?

> sling listener crashes - cannot reliably start sling
> 
>
> Key: SLING-6615
> URL: https://issues.apache.org/jira/browse/SLING-6615
> Project: Sling
>  Issue Type: Bug
> Environment: linux (centos 5.x / fedora 22)
> java 8 update 111
>Reporter: Andrea Biardi
> Attachments: log, sling_test.sh
>
>
> In my production environment I use a script to upload contents to an instance 
> of sling. Occasionally, I get "Connection refused" errors (I use curl for the 
> uploads).
> Thinking of a problem with my own customizations, I wrote a shell script from 
> scratch, using the discover-sling-in-15-minutes webpage as a reference. I'm 
> attaching the script for reference (careful: it will kill any existing 
> sling.launchpad process).
> I may be doing something wrong here, but this is what I notice:
> - During startup, sling produces a lot of spurious http errors (401,403,503); 
> I believe this is expected, as sling is still booting up.
> - When I'm finally able to upload some content, and I try to retrieve it 
> back, I seem to hit some kind of race condition that shuts down the listener 
> process.
> The crash doesn't happen every time, but still fairly often (say 1 out of 5 
> or 10 runs). When it does, I can see that netstat reports no processes 
> listening on port 8080, although the java PID is still alive. Seems like the 
> listener has crashed, and I have to kill the PID and restart sling.
> Attached is a log of the output from a problematic run (./sling_test 2>&1 | 
> tee log); as you can see towards the end of the file, the loop is stuck in a 
> "Connection refused" error that will never recover.
> At the prompt, I can verify that the sling.launchpad process is still 
> running, however it's no longer listening on port 8080:
> [root@ sl8]# ps axf | grep launchpad
>  3486 pts/0S+ 0:00  \_ grep --color=auto launchpad
>  3076 pts/0Sl 0:21 java -jar org.apache.sling.launchpad-8.jar
> [root@ sl8]# cat /proc/3076/cmdline
> java-jarorg.apache.sling.launchpad-8.jar
> [root@ sl8]# netstat -lnp | grep 8080
> [root@ sl8]#
> Am I doing something wrong or is this a known issue and if so - is there a 
> workaround?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (SLING-6615) sling listener crashes - cannot reliably start sling

2017-03-06 Thread Andrea Biardi (JIRA)
Andrea Biardi created SLING-6615:


 Summary: sling listener crashes - cannot reliably start sling
 Key: SLING-6615
 URL: https://issues.apache.org/jira/browse/SLING-6615
 Project: Sling
  Issue Type: Bug
 Environment: linux (centos 5.x / fedora 22)
java 8 update 111
Reporter: Andrea Biardi
 Attachments: log, sling_test.sh


In my production environment I use a script to upload contents to an instance 
of sling. Occasionally, I get "Connection refused" errors (I use curl for the 
uploads).

Thinking of a problem with my own customizations, I wrote a shell script from 
scratch, using the discover-sling-in-15-minutes webpage as a reference. I'm 
attaching the script for reference (careful: it will kill any existing 
sling.launchpad process).

I may be doing something wrong here, but this is what I notice:
- During startup, sling produces a lot of spurious http errors (401,403,503); I 
believe this is expected, as sling is still booting up.
- When I'm finally able to upload some content, and I try to retrieve it back, 
I seem to hit some kind of race condition that shuts down the listener process.

The crash doesn't happen every time, but still fairly often (say 1 out of 5 or 
10 runs). When it does, I can see that netstat reports no processes listening 
on port 8080, although the java PID is still alive. Seems like the listener has 
crashed, and I have to kill the PID and restart sling.

Attached is a log of the output from a problematic run (./sling_test 2>&1 | tee 
log); as you can see towards the end of the file, the loop is stuck in a 
"Connection refused" error that will never recover.

At the prompt, I can verify that the sling.launchpad process is still running, 
however it's no longer listening on port 8080:

[root@ sl8]# ps axf | grep launchpad
 3486 pts/0S+ 0:00  \_ grep --color=auto launchpad
 3076 pts/0Sl 0:21 java -jar org.apache.sling.launchpad-8.jar
[root@ sl8]# cat /proc/3076/cmdline
java-jarorg.apache.sling.launchpad-8.jar
[root@ sl8]# netstat -lnp | grep 8080
[root@ sl8]#

Am I doing something wrong or is this a known issue and if so - is there a 
workaround?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: svn commit: r1785487 - in /sling/trunk/testing/org.apache.sling.testing.paxexam: ./ src/main/java/org/apache/sling/testing/paxexam/ src/test/java/org/apache/sling/testing/paxexam/ src/test/resourc

2017-03-06 Thread Julian Sedding
I think that's not necessary. It's all in the svn history and the
revision numbers are referenced from the ticket.

Regards
Julian

On Mon, Mar 6, 2017 at 12:55 PM, Oliver Lietz  wrote:
> On Monday 06 March 2017 12:27:28 Julian Sedding wrote:
>> Thanks for reverting these changes, Olli. I meant to do the same for
>> some time, but never got around to it.
>>
>> I think this idea need more thought and work before it can become truly
>> useful.
>
> Should we add a reverse patch containing your work to SLING-6473?
>
> Regards,
> O.
>
>> Regards
>> Julian
>>
>> On Sat, Mar 4, 2017 at 2:58 PM,   wrote:
>> > Author: olli
>> > Date: Sat Mar  4 13:58:36 2017
>> > New Revision: 1785487
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1785487=rev
>> > Log:
>> > SLING-6473 Create a VersionResolver that provides versions from
>> > provisioning model files
>> >
>> > remove VersionResolver until matching Options are also provided by
>> > provisioning model>
>> > Removed:
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org
>> > /apache/sling/testing/paxexam/ProvisioningModelVersionResolver.java
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/or
>> > g/apache/sling/testing/paxexam/ProvisioningModelVersionResolverTest.ja
>> > va
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/resourc
>> > es/>
>> > Modified:
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org
>> > /apache/sling/testing/paxexam/SlingOptionsTestSupport.java>
>> > Modified: sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
>> > URL:
>> > http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing
>> > .paxexam/pom.xml?rev=1785487=1785486=1785487=diff
>> > =
>> > = --- sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
>> > (original) +++
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml Sat Mar  4
>> > 13:58:36 2017 @@ -105,13 +105,6 @@
>> >
>> >osgi.cmpn
>> >provided
>> >
>> >  
>> >
>> > -
>> > -  org.apache.sling
>> > -  org.apache.sling.provisioning.model
>> > -  1.0.0
>> > -  provided
>> > -  true
>> > -
>> >
>> >  
>> >  
>> >
>> >org.apache.felix
>> >
>> > @@ -153,12 +146,6 @@
>> >
>> >${org.ops4j.pax.exam.version}
>> >test
>> >
>> >  
>> >
>> > -
>> > -  org.slf4j
>> > -  slf4j-simple
>> > -  1.7.13
>> > -  test
>> > -
>> >
>> >
>> >
>> >  
>> >
>> > Modified:
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
>> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java URL:
>> > http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing
>> > .paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSu
>> > pport.java?rev=1785487=1785486=1785487=diff
>> > =
>> > = ---
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
>> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java (original) +++
>> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
>> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java Sat Mar  4
>> > 13:58:36 2017 @@ -18,13 +18,11 @@
>> >
>> >   */
>> >
>> >  package org.apache.sling.testing.paxexam;
>> >
>> > -
>> >
>> >  import org.ops4j.pax.exam.CoreOptions;
>> >  import org.ops4j.pax.exam.Option;
>> >
>> >  import static org.ops4j.pax.exam.CoreOptions.composite;
>> >  import static org.ops4j.pax.exam.CoreOptions.keepCaches;
>> >
>> > -import static org.ops4j.pax.exam.CoreOptions.mavenBundle;
>> >
>> >  public abstract class SlingOptionsTestSupport extends TestSupport {
>
>


[jira] [Comment Edited] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus edited comment on SLING-6610 at 3/6/17 3:18 PM:


I am open for other proposals, but basically I need to transmit information 
about the validators severity from the {{ValidationModelRetrieverImpl}} to the 
{{ResourceModelProvider}}. Otherwise I don't have the information about the 
validator severity in the {{ParameterizedValidator}}.


was (Author: kwin):
I am open for other proposals, but basically I need to transmit information 
about the validators severity from the {{ValidationModelRetrieverImpl}} to the 
{{ResourceModelProvider}}s. Otherwise I don't have the information about the 
validator severity in the {{ParameterizedValidator}}.

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6610:


I am open for other proposals, but basically I need to transmit information 
about the validators severity from the {{ValidationModelRetrieverImpl}} to the 
{{ResourceModelProvider}}s. Otherwise I don't have the information about the 
validator severity in the {{ParameterizedValidator}}.

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6609:


Extended the javadoc with [r1785659|http://svn.apache.org/r1785659]. 
[~fmeschbe] Could you quickly cross-check?

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Julian Sedding (JIRA)

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

Julian Sedding commented on SLING-6609:
---

bq. Maybe you could add the annotation plus add an implementation note, that 
implementations should treat being called with {{defaultValue==null}} 
equivalent to {{get(String)}} and thus to check for {{null}}.

That sounds reasonable and strikes a nice balance between backwards 
compatibility and clarification/evolution of the API contract.

bq. Of course this is debatable and in hind sight we should have properly 
define the API such that defaultValue must not be null (with the respective 
runtime check on implementations). But we are where we are.

Indeed. Hind sight is a luxury we rarely have in the beginning ;)

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (SLING-6614) JcrContentLoader should ignore protected nodes and properties

2017-03-06 Thread Guillaume Lucazeau (JIRA)
Guillaume Lucazeau created SLING-6614:
-

 Summary: JcrContentLoader should ignore protected nodes and 
properties
 Key: SLING-6614
 URL: https://issues.apache.org/jira/browse/SLING-6614
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Guillaume Lucazeau


When exporting node tree from Sling as JSON, it would be nice to be able to 
import it directly into another path or JCR repository.

Currently, this is not possible as the export contains protected properties 
("jcr:created") and protected nodes (ACLs).

The content loader should ignore them and process the other content.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6613) ResourceResolverFactory not registered when legacy configuration references JcrResourceProviderFactory

2017-03-06 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-6613:
---
Attachment: 0001-SLING-6613-ResourceResolverFactory-not-registered-wh.patch

[~cziegeler] - WDYT?

> ResourceResolverFactory not registered when legacy configuration references 
> JcrResourceProviderFactory
> --
>
> Key: SLING-6613
> URL: https://issues.apache.org/jira/browse/SLING-6613
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Resource Resolver 1.5.18
>
> Attachments: 
> 0001-SLING-6613-ResourceResolverFactory-not-registered-wh.patch
>
>
> The fix for SLING-6469 references a legacy service pid of 
> {{org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider}}. 
> However, in my tests the actual pid is 
> {{org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory}}
>  ( note the factory at the end ).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (SLING-6613) ResourceResolverFactory not registered when legacy configuration references JcrResourceProviderFactory

2017-03-06 Thread Robert Munteanu (JIRA)
Robert Munteanu created SLING-6613:
--

 Summary: ResourceResolverFactory not registered when legacy 
configuration references JcrResourceProviderFactory
 Key: SLING-6613
 URL: https://issues.apache.org/jira/browse/SLING-6613
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Resource Resolver 1.5.18


The fix for SLING-6469 references a legacy service pid of 
{{org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider}}. 
However, in my tests the actual pid is 
{{org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory}}
 ( note the factory at the end ).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling XSS 1.0.18

2017-03-06 Thread Daniel Klco
+1 checked signatures and build

On Mon, Mar 6, 2017 at 4:01 AM, Robert Munteanu  wrote:

> On Fri, 2017-03-03 at 10:02 +0100, Oliver Lietz wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert


[jira] [Updated] (SLING-6612) HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository

2017-03-06 Thread Vlad Bailescu (JIRA)

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

Vlad Bailescu updated SLING-6612:
-
Attachment: SLING-6612-test.patch

> HTL/Sightly sometimes fails to recompile an updated Java POJO located in the 
> repository
> ---
>
> Key: SLING-6612
> URL: https://issues.apache.org/jira/browse/SLING-6612
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Vlad Bailescu
>Priority: Critical
> Attachments: SLING-6612-test.patch
>
>
> HTL/Sightly sometimes fails to recompile an updated Java POJO located in the 
> repository because the current implementation of the {{JavaUseProvider}} does 
> not take into account the timestamps of the {{.java}} and {{.class}} files 
> (and relies on {{ResourceChangeListener}} to track updates to the Java 
> classes in the repo).
> I have attached a patch with a test that reproduces the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (SLING-6612) HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository

2017-03-06 Thread Vlad Bailescu (JIRA)
Vlad Bailescu created SLING-6612:


 Summary: HTL/Sightly sometimes fails to recompile an updated Java 
POJO located in the repository
 Key: SLING-6612
 URL: https://issues.apache.org/jira/browse/SLING-6612
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.18
Reporter: Vlad Bailescu
Priority: Critical


HTL/Sightly sometimes fails to recompile an updated Java POJO located in the 
repository because the current implementation of the {{JavaUseProvider}} does 
not take into account the timestamps of the {{.java}} and {{.class}} files (and 
relies on {{ResourceChangeListener}} to track updates to the Java classes in 
the repo).

I have attached a patch with a test that reproduces the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: svn commit: r1785487 - in /sling/trunk/testing/org.apache.sling.testing.paxexam: ./ src/main/java/org/apache/sling/testing/paxexam/ src/test/java/org/apache/sling/testing/paxexam/ src/test/resourc

2017-03-06 Thread Oliver Lietz
On Monday 06 March 2017 12:27:28 Julian Sedding wrote:
> Thanks for reverting these changes, Olli. I meant to do the same for
> some time, but never got around to it.
> 
> I think this idea need more thought and work before it can become truly
> useful.

Should we add a reverse patch containing your work to SLING-6473?

Regards,
O.

> Regards
> Julian
> 
> On Sat, Mar 4, 2017 at 2:58 PM,   wrote:
> > Author: olli
> > Date: Sat Mar  4 13:58:36 2017
> > New Revision: 1785487
> > 
> > URL: http://svn.apache.org/viewvc?rev=1785487=rev
> > Log:
> > SLING-6473 Create a VersionResolver that provides versions from
> > provisioning model files
> > 
> > remove VersionResolver until matching Options are also provided by
> > provisioning model> 
> > Removed:
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org
> > /apache/sling/testing/paxexam/ProvisioningModelVersionResolver.java
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/or
> > g/apache/sling/testing/paxexam/ProvisioningModelVersionResolverTest.ja
> > va
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/resourc
> > es/> 
> > Modified:
> > sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org
> > /apache/sling/testing/paxexam/SlingOptionsTestSupport.java> 
> > Modified: sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing
> > .paxexam/pom.xml?rev=1785487=1785486=1785487=diff
> > =
> > = --- sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
> > (original) +++
> > sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml Sat Mar  4
> > 13:58:36 2017 @@ -105,13 +105,6 @@
> > 
> >osgi.cmpn
> >provided
> >  
> >  
> > 
> > -
> > -  org.apache.sling
> > -  org.apache.sling.provisioning.model
> > -  1.0.0
> > -  provided
> > -  true
> > -
> > 
> >  
> >  
> >  
> >org.apache.felix
> > 
> > @@ -153,12 +146,6 @@
> > 
> >${org.ops4j.pax.exam.version}
> >test
> >  
> >  
> > 
> > -
> > -  org.slf4j
> > -  slf4j-simple
> > -  1.7.13
> > -  test
> > -
> > 
> >
> >  
> >  
> > 
> > Modified:
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java URL:
> > http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing
> > .paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSu
> > pport.java?rev=1785487=1785486=1785487=diff
> > =
> > = ---
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java (original) +++
> > sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/ap
> > ache/sling/testing/paxexam/SlingOptionsTestSupport.java Sat Mar  4
> > 13:58:36 2017 @@ -18,13 +18,11 @@
> > 
> >   */
> >  
> >  package org.apache.sling.testing.paxexam;
> > 
> > -
> > 
> >  import org.ops4j.pax.exam.CoreOptions;
> >  import org.ops4j.pax.exam.Option;
> >  
> >  import static org.ops4j.pax.exam.CoreOptions.composite;
> >  import static org.ops4j.pax.exam.CoreOptions.keepCaches;
> > 
> > -import static org.ops4j.pax.exam.CoreOptions.mavenBundle;
> > 
> >  public abstract class SlingOptionsTestSupport extends TestSupport {




Re: [VOTE] Release Apache Sling Distributed Event Admin 1.1.2

2017-03-06 Thread Daniel Klco
+1

On Mon, Mar 6, 2017 at 3:48 AM, Robert Munteanu  wrote:

> On Sun, 2017-03-05 at 08:40 +0100, Oliver Lietz wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Felix Meschberger (JIRA)

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

Felix Meschberger commented on SLING-6609:
--

Fully agreed with the safety net for compile time check as well as for 
documentation of adding this annotation.

The question about historic and so is whether this change actually changes 
semantics and/or existing expectations of the API. The documentation is not 
very clear right now, unfortunately.

For example, assume that historically we accepted null as can be seen from the 
ValueMapDecorator implementation. Now, we describe the API to not take null any 
longer. So a new implementation of course will not check for null and run into 
an NPE (which is fine because the API is not used according to the contract) 
while an old consumer who was assuming null to be ok as it has been so far 
might now run into that unexpected NPE.

Maybe you could add the annotation plus add an implementation note, that 
implementations should treat being called with {{defaultValue==null}} 
equivalent to {{get(String)}} and thus to check for {{null}}.

Of course this is debatable and in hind sight we should have properly define 
the API such that defaultValue must not be null (with the respective runtime 
check on implementations). But we are where we are.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz commented on SLING-6610:
-

I have to look closer, but {{ValidatorAndSeverity}} feels odd.

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6502) JSP: java.lang.VerifyError (Bad type on operand stack)

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz commented on SLING-6502:
-

[~cziegeler], [~fmeschbe]: as Felix raised concerns, how do we proceed?

The smallest change to Lauchpad would be wrapping {{jsp-api}} and {{el-api}} 
(similar to {{javax.jcr}}) from Apache Tomcat (6.0.14) and adding both to 
Launchpad.

Also removing Scripting JSP (and therefore Sightly/HTL\[?] and Composum) from 
Karaf Features/Distribution is an option.

> JSP: java.lang.VerifyError (Bad type on operand stack)
> --
>
> Key: SLING-6502
> URL: https://issues.apache.org/jira/browse/SLING-6502
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.2.6
> Environment: Apache Karaf 4.1.0-SNAPSHOT (Pax Web 6.0.2)
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JSP 2.2.8
>
> Attachments: apis.patch
>
>
> {{org.apache.sling.scripting.jsp}} embeds {{jsp-api}} and {{el-api}} from 
> Apache Tomcat ({{6.0.14}}) which causes this error.
> {noformat}
> [...]
> [httpclient.wire.header] : << "HTTP/1.1 500 Server Error[\r][\n]"
> [httpclient.wire.header] : << "Content-Type: text/html;charset=utf-8[\r][\n]"
> [httpclient.wire.header] : << "Transfer-Encoding: chunked[\r][\n]"
> [httpclient.wire.header] : << "Server: Jetty(9.3.15.v20161220)[\r][\n]"
> [httpclient.wire.header] : << "[\r][\n]"
> [httpclient.wire.content] : << "B"
> [httpclient.wire.content] : << "5"
> [httpclient.wire.content] : << "1"
> [httpclient.wire.content] : << "[\r]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "java.lang.VerifyError: Bad type on operand 
> stack[\n]"
> [httpclient.wire.content] : << "Exception Details:[\n]"
> [httpclient.wire.content] : << "  Location:[\n]"
> [httpclient.wire.content] : << "
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl.createELResolver()Ljavax/el/ELResolver;
>  @28: invokevirtual[\n]"
> [httpclient.wire.content] : << "  Reason:[\n]"
> [httpclient.wire.content] : << "Type 
> javax/servlet/jsp/el/ImplicitObjectELResolver (current frame, 
> stack[1]) is not assignable to javax/el/ELResolver[\n]"
> [httpclient.wire.content] : << "  Current Frame:[\n]"
> [httpclient.wire.content] : << "bci: @28[\n]"
> [httpclient.wire.content] : << "flags: { }[\n]"
> [httpclient.wire.content] : << "locals: { 
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl,
>  javax/el/CompositeELResolver }[\n]"
> [httpclient.wire.content] : << "stack: { 
> javax/el/CompositeELResolver, 
> javax/servlet/jsp/el/ImplicitObjectELResolver }[\n]"
> [httpclient.wire.content] : << "  Bytecode:[\n]"
> [httpclient.wire.content] : << "0x000: 2a04 b500 062a b400 1dc7 0080 
> bb00 1e59[\n]"
> [httpclient.wire.content] : << "0x010: b700 1f4c 2bbb 0020 59b7 0021 
> b600 222a[\n]"
> [httpclient.wire.content] : << "0x020: b400 05b9 0023 0100 4d2c b900 
> 2401 0099[\n]"
> [httpclient.wire.content] : << "0x030: 0013 2b2c b900 2501 00c0 0026 
> b600 22a7[\n]"
> [httpclient.wire.content] : << "0x040: ffea 2bbb 0027 59b7 0028 b600 
> 222b bb00[\n]"
> [httpclient.wire.content] : << "0x050: 2959 b700 2ab6 0022 2bbb 002b 
> 59b7 002c[\n]"
> [httpclient.wire.content] : << "0x060: b600 222b bb00 2d59 b700 2eb6 
> 0022 2bbb[\n]"
> [httpclient.wire.content] : << "0x070: 002f 59b7 0030 b600 222b bb00 
> 3159 b700[\n]"
> [httpclient.wire.content] : << "0x080: 32b6 0022 2a2b b500 1d2a b400 
> 1db0 [\n]"
> [httpclient.wire.content] : << "  Stackmap Table:[\n]"
> [httpclient.wire.content] : << "
> append_frame(@41,Object[#112],Object[#113])[\n]"
> [httpclient.wire.content] : << "chop_frame(@66,1)[\n]"
> [httpclient.wire.content] : << "chop_frame(@137,1)[\n]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "[\n]"
> [...]
> {noformat}
> {noformat}
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>   Location:
> 
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl.createELResolver()Ljavax/el/ELResolver;
>  @28: invokevirtual
>   Reason:
> Type javax/servlet/jsp/el/ImplicitObjectELResolver (current 
> frame, stack[1]) is not assignable to javax/el/ELResolver
>   Current Frame:
> bci: @28
> flags: { }
> locals: { 
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl,
>  javax/el/CompositeELResolver }
> stack: { javax/el/CompositeELResolver, 
> javax/servlet/jsp/el/ImplicitObjectELResolver }
>   Bytecode:
> 0x000: 2a04 b500 062a b400 1dc7 0080 bb00 1e59
> 0x010: b700 1f4c 2bbb 

Re: svn commit: r1785487 - in /sling/trunk/testing/org.apache.sling.testing.paxexam: ./ src/main/java/org/apache/sling/testing/paxexam/ src/test/java/org/apache/sling/testing/paxexam/ src/test/resourc

2017-03-06 Thread Julian Sedding
Thanks for reverting these changes, Olli. I meant to do the same for
some time, but never got around to it.

I think this idea need more thought and work before it can become truly useful.

Regards
Julian


On Sat, Mar 4, 2017 at 2:58 PM,   wrote:
> Author: olli
> Date: Sat Mar  4 13:58:36 2017
> New Revision: 1785487
>
> URL: http://svn.apache.org/viewvc?rev=1785487=rev
> Log:
> SLING-6473 Create a VersionResolver that provides versions from provisioning 
> model files
>
> remove VersionResolver until matching Options are also provided by 
> provisioning model
>
> Removed:
> 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org/apache/sling/testing/paxexam/ProvisioningModelVersionResolver.java
> 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/ProvisioningModelVersionResolverTest.java
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/resources/
> Modified:
> sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
> 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSupport.java
>
> Modified: sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml?rev=1785487=1785486=1785487=diff
> ==
> --- sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml (original)
> +++ sling/trunk/testing/org.apache.sling.testing.paxexam/pom.xml Sat Mar  4 
> 13:58:36 2017
> @@ -105,13 +105,6 @@
>osgi.cmpn
>provided
>  
> -
> -  org.apache.sling
> -  org.apache.sling.provisioning.model
> -  1.0.0
> -  provided
> -  true
> -
>  
>  
>org.apache.felix
> @@ -153,12 +146,6 @@
>${org.ops4j.pax.exam.version}
>test
>  
> -
> -  org.slf4j
> -  slf4j-simple
> -  1.7.13
> -  test
> -
>
>
>  
>
> Modified: 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSupport.java
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSupport.java?rev=1785487=1785486=1785487=diff
> ==
> --- 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSupport.java
>  (original)
> +++ 
> sling/trunk/testing/org.apache.sling.testing.paxexam/src/test/java/org/apache/sling/testing/paxexam/SlingOptionsTestSupport.java
>  Sat Mar  4 13:58:36 2017
> @@ -18,13 +18,11 @@
>   */
>  package org.apache.sling.testing.paxexam;
>
> -
>  import org.ops4j.pax.exam.CoreOptions;
>  import org.ops4j.pax.exam.Option;
>
>  import static org.ops4j.pax.exam.CoreOptions.composite;
>  import static org.ops4j.pax.exam.CoreOptions.keepCaches;
> -import static org.ops4j.pax.exam.CoreOptions.mavenBundle;
>
>  public abstract class SlingOptionsTestSupport extends TestSupport {
>
>
>


[jira] [Resolved] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

2017-03-06 Thread Julian Sedding (JIRA)

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

Julian Sedding resolved SLING-6473.
---
Resolution: Later

Changes reverted in [r1785487|https://svn.apache.org/r1785487] by [~olli].
I still believe that the idea has potential, but the crude first draft I 
provided had only limited usefulness. Since I currently don't have a need for 
it, nor the time to work on it, I am closing this issue with resolution "later".

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling Scripting Core 2.0.46

2017-03-06 Thread Karl Pauls
+1

regards,

Karl

On Mon, Mar 6, 2017 at 9:49 AM, Robert Munteanu  wrote:
> On Fri, 2017-03-03 at 11:42 +0100, Oliver Lietz wrote:
>> Please vote to approve this release:
>
> +1
>
> Robert



-- 
Karl Pauls
karlpa...@gmail.com


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Julian Sedding (JIRA)

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

Julian Sedding commented on SLING-6609:
---

I agree with [~kwin] on this one. Especially since we have explicit support for 
the {{null}} default value (aka. no default value):

{code}
// assuming "properties" is a ValueMap instance and the property "nonExistant" 
does not exist, then
assert null == properties.get("nonExistant", (String)null);
// is equivalent to
assert null == properties.get("nonExistant", String.class);
{code}

Or am I missing something?

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling i18n 2.5.8

2017-03-06 Thread Karl Pauls
+1

regards,

Karl

On Fri, Mar 3, 2017 at 5:20 PM, Daniel Klco  wrote:
> +1
>
> On Fri, Mar 3, 2017 at 4:29 AM, Timothee Maret  wrote:
>
>> +1 (non binding)
>>
>> Regards,
>>
>> Timothee
>>
>> 2017-03-03 9:15 GMT+01:00 Oliver Lietz :
>>
>> > Hi,
>> >
>> > we solved 2 issues in this release:
>> > https://issues.apache.org/jira/browse/SLING/fixforversion/12338904
>> >
>> > Staging repository:
>> > https://repository.apache.org/content/repositories/orgapachesling-1652/
>> >
>> > 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 1652 /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,
>> > O.
>> >
>> >
>>



-- 
Karl Pauls
karlpa...@gmail.com


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6609:


Even if it was historically supported, I don't think it was useful with a 2nd 
parameter being {{null}}. Also the annotations don't touch the implementation 
(so passing {{null}} will still work). 

It is just that if you use findbugs or Eclipse with null analysis enabled this 
will emit a warning if you pass a {{null}} parameter. The other alternative 
would be to annotate the return value to {{@CheckForNull}} which is not true in 
99% of the cases and therefore requires you to more often check for a null 
return value.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Jenkins build failures (Parent 30)

2017-03-06 Thread Oliver Lietz
hi,

sorry for the noise – Parent 30 was not available in Maven Central (it is 
now).

O.



[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Felix Meschberger (JIRA)

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

Felix Meschberger commented on SLING-6609:
--

Ah, right, but historically, I am not sure, this really was the intent. 
Particularly if you look at the [ValueMapDecorator 
implementation|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/wrappers/ValueMapDecorator.java#L63]
 where there is an explicit {{null}} guard 

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus resolved SLING-6610.

Resolution: Fixed
  Assignee: Konrad Windszus

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6610) DefaultValidationFailure and DefaultValidationResult should use ValidationContext as parameter

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6610:


Fixed in [r1785616|http://svn.apache.org/r1785616]. I also straightened up the 
severity handling.

> DefaultValidationFailure and DefaultValidationResult should use 
> ValidationContext as parameter
> --
>
> Key: SLING-6610
> URL: https://issues.apache.org/jira/browse/SLING-6610
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
> Fix For: Validation 1.0.0
>
>
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull ValidationContext validationContext, 
> @Nonnull String messageKey, Object... messageArguments)
> {noformat}
> instead of {{location}}, {{severity}} and {{ResourceBundle}} from 
> {{ValidationContext}}:
> {noformat}
> public DefaultValidationFailure(@Nonnull String location, Integer severity, 
> @Nonnull ResourceBundle defaultResourceBundle, @Nonnull String messageKey, 
> Object... messageArguments)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6246) Update to latest maven scr plugin and scr annotations

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6246.
---

> Update to latest maven scr plugin and scr annotations
> -
>
> Key: SLING-6246
> URL: https://issues.apache.org/jira/browse/SLING-6246
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Parent 30
>
>
> org.apache.felix:maven-scr-plugin .. 1.22.0 -> 1.23.0
> org.apache.felix:org.apache.felix.scr.annotations ... 1.11.0 -> 1.12.0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6560) Exclude Lucene's index-details.txt from Rat checks

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6560.
---

> Exclude Lucene's index-details.txt from Rat checks
> --
>
> Key: SLING-6560
> URL: https://issues.apache.org/jira/browse/SLING-6560
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: Parent 30
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6532.
---

> No longer add the Felix SCR annotations to the list of dependencies
> ---
>
> Key: SLING-6532
> URL: https://issues.apache.org/jira/browse/SLING-6532
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> To encourage more modules to switch to OSGi 6 annotations, we should not only 
> mark the dependency with the (invisible) comment {{DEPRECATED}} (as being 
> done with SLING-5857), but instead no longer put that dependency by default 
> into the classpath. Just having that in the dependencyManagement is enough, 
> so that for new modules already leveraging only the new annotations the 
> classpath is no longer polluted by this unnecessary class.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6572) Generate SCR metadata required for mock-based unit tests

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6572.
---

> Generate SCR metadata required for mock-based unit tests
> 
>
> Key: SLING-6572
> URL: https://issues.apache.org/jira/browse/SLING-6572
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 29
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Parent 30
>
>
> when unit tests are based on osgi-mock the SCR metadata generated for the 
> OSGi components of the project itself needs to be present in the generated 
> classpath before the unit test run.
> the following {{maven-bundle-plugin}} configuration is required for this:
> {code:xml}
> 
> 
> 
> true
> 
> 
> 
> 
> scr-metadata
> 
> manifest
> 
> 
> true
> 
> 
> 
> {code}
> we should add it by default to the global parent pom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6245) Add odd-even release policy to release plugin

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6245.
---

> Add odd-even release policy to release plugin
> -
>
> Key: SLING-6245
> URL: https://issues.apache.org/jira/browse/SLING-6245
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Parent 30
>
>
> We follow the odd / even policy for releases, the maven release plugin 
> supports this since version 2.5.3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6533) No longer add bndlib to the list of commons dependencies

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6533.
---

> No longer add bndlib to the list of commons dependencies
> 
>
> Key: SLING-6533
> URL: https://issues.apache.org/jira/browse/SLING-6533
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> The bndlib dependency was used in the past for the semantic versioning 
> annotations. Now that OSGi has its own annotations, that library should no 
> longer be part of the common inherited dependencies.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (SLING-6611) Improve FileVaultContentSerializer performance

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret reassigned SLING-6611:
-

Assignee: Timothee Maret

> Improve FileVaultContentSerializer performance
> --
>
> Key: SLING-6611
> URL: https://issues.apache.org/jira/browse/SLING-6611
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
>
> It would be good if we could improve FileVault serializer performance by 
> avoiding writing several (temp) files on FS and avoid compressing binaries 
> that are already compressed (e.g. images like jpg, png, etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6609:


The default value is also supposed to be not null (therefore carries the 
annotation @Nonnull as well).

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

2017-03-06 Thread Felix Meschberger (JIRA)

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

Felix Meschberger commented on SLING-6609:
--

Actually, I am not entirely sure, whether @Nonnull is technically entirely 
correct: The spec says, to return the named property or the {{defaultValue}}. 
What if the {{defaultValue}} is {{null}} ?

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling Parent 30

2017-03-06 Thread Oliver Lietz
On Thursday 02 March 2017 13:40:41 Oliver Lietz wrote:
> Hi,
> 
> we solved 6 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338540

+1

O.



[jira] [Created] (SLING-6611) Improve FileVaultContentSerializer performance

2017-03-06 Thread Tommaso Teofili (JIRA)
Tommaso Teofili created SLING-6611:
--

 Summary: Improve FileVaultContentSerializer performance
 Key: SLING-6611
 URL: https://issues.apache.org/jira/browse/SLING-6611
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


It would be good if we could improve FileVault serializer performance by 
avoiding writing several (temp) files on FS and avoid compressing binaries that 
are already compressed (e.g. images like jpg, png, etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[RESULT] [VOTE] Release Apache Sling Parent 30

2017-03-06 Thread Oliver Lietz
Hi,

the vote has passed with the following result:

+1 (binding): Carsten Ziegeler, Robert Munteanu, Radu Cotescu, Stefan Seifert, 
Daniel Klco, Oliver Lietz

I will copy this release to the Sling dist directory and promote the artifacts 
to the central Maven repository.

Thanks for voting!

O.



Re: [VOTE] Release Apache Sling JCR Installer 3.1.24

2017-03-06 Thread Timothee Maret
+1 (non binding)

2017-03-03 9:49 GMT+01:00 Oliver Lietz :

> Hi,
>
> we solved 2 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338806
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1653/
>
> 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 1653 /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,
> O.
>
>


Re: [VOTE] Release Apache Sling Event 4.2.2

2017-03-06 Thread Robert Munteanu
On Sun, 2017-03-05 at 08:29 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

BTW, https://issues.apache.org/jira/browse/SLING-6287 should be moved
to the next release.

Robert

signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Release Apache Sling Health Check Core 1.2.6

2017-03-06 Thread Robert Munteanu
On Fri, 2017-03-03 at 15:23 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Release Apache Sling Scripting HTL JavaScript Use Provider 1.0.20

2017-03-06 Thread Robert Munteanu
On Fri, 2017-03-03 at 10:18 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Release Apache Sling XSS 1.0.18

2017-03-06 Thread Robert Munteanu
On Fri, 2017-03-03 at 10:02 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Release Apache Sling Health Check Core 1.2.6

2017-03-06 Thread Timothee Maret
+1 (not binding)

2017-03-03 15:23 GMT+01:00 Oliver Lietz :

> Hi,
>
> we solved 7 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12335062
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1657/
>
> 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 1657 /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,
> O.
>
>


Re: [VOTE] Release Apache Sling JCR Installer 3.1.24

2017-03-06 Thread Robert Munteanu
On Fri, 2017-03-03 at 09:49 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


[jira] [Closed] (SLING-6430) Documentation IDE Tooling

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-6430.
---

> Documentation IDE Tooling
> -
>
> Key: SLING-6430
> URL: https://issues.apache.org/jira/browse/SLING-6430
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>Reporter: Frederik Fromm
>Assignee: Oliver Lietz
>  Labels: documentation
>
> Please remove this page from 2010: 
> https://cwiki.apache.org/confluence/display/SLING/Setting+up+Eclipse+3.4+for+Sling
>  found on http://sling.apache.org/documentation/getting-started.html
> or replace it by 
> http://sling.apache.org/documentation/development/ide-tooling.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling Scripting Core 2.0.46

2017-03-06 Thread Robert Munteanu
On Fri, 2017-03-03 at 11:42 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Release Apache Sling Distributed Event Admin 1.1.2

2017-03-06 Thread Robert Munteanu
On Sun, 2017-03-05 at 08:40 +0100, Oliver Lietz wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part


Re: [RESULT] [VOTE] Release Apache Sling Content Distribution Core version 0.2.6

2017-03-06 Thread Timothee Maret
Thanks Oliver!

I have done the remaining steps.

Regards,

Timothee

2017-03-06 9:36 GMT+01:00 Oliver Lietz :

> On Monday 06 March 2017 09:29:28 Timothee Maret wrote:
> > Hi,
> >
> > The vote has passed with the following result :
> >
> > +1 (binding): Oliver Lietz, Robert Munteanu, Daniel Klco
> > +1 (non binding): Tommaso Teofili
> >
> > Could a member of the @PMC please push the release to
> > https://dist.apache.org/repos/dist/release/sling ?
>
> Done.
>
> O.
>
> > I'll take care of the remaining steps once this is done.
>
>


[jira] [Closed] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

2017-03-06 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-5888.
---

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Health Checks 1.0.0
>
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[RESULT] [VOTE] Release Apache Sling Installer Health Checks 1.0.0

2017-03-06 Thread Oliver Lietz
Hi,

the vote has passed with the following result:

+1 (binding): Konrad Windszus, Carsten Ziegeler, Robert Munteanu, Daniel Klco, 
Oliver Lietz
+1 (non-binding): Timothee Maret

I will copy this release to the Sling dist directory and promote the artifacts 
to the central Maven repository.

Thanks for voting!

O.



[jira] [Updated] (SLING-5916) Remove all usages of jobManager.findJobs in SCD

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret updated SLING-5916:
--
Fix Version/s: (was: Content Distribution Core 0.2.6)
   Content Distribution Core 0.2.8

> Remove all usages of jobManager.findJobs in SCD
> ---
>
> Key: SLING-5916
> URL: https://issues.apache.org/jira/browse/SLING-5916
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
>
> Given the latest discussions on the Sling dev@ list it'd be good to stop 
> using {{JobManager#findJobs}} API at all in the SCD code (for the jobs based 
> queues).
> This would require either accepting queues cannot be inspected in detail 
> (which / how many items there are in each queue) or rely on different 
> constructs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-4797) Improve handling of Move events

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret updated SLING-4797:
--
Fix Version/s: (was: Content Distribution Core 0.2.6)
   Content Distribution Core 0.2.8

> Improve handling of Move events
> ---
>
> Key: SLING-4797
> URL: https://issues.apache.org/jira/browse/SLING-4797
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.4
>Reporter: Konrad Windszus
> Fix For: Content Distribution Core 0.2.8
>
>
> In case you are moving a node with a lot of subnodes, this leads to a 
> distributed deletion of the node, followed by the distributed addition of the 
> node with all subnodes.
> To improve the performance it would be good, if the move operation would 
> really be distributed through a move event, which means that each receiver 
> would try to move the node (instead of first deleting it and then adding it 
> with all its subnodes).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-5760) Allow to support certificate based authentication in Distribution transport

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret updated SLING-5760:
--
Fix Version/s: (was: Content Distribution Core 0.2.6)
   Content Distribution Core 0.2.8

> Allow to support certificate based authentication in Distribution transport
> ---
>
> Key: SLING-5760
> URL: https://issues.apache.org/jira/browse/SLING-5760
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-5760.patch
>
>
> Certificate based authentication is an alternative to the basic 
> authentication currently available for Distribution transport. Certificate 
> based authentication is done during the SSL handshake iff the target instance 
> is configured to require or accept client client authentication. This client 
> authentication scheme is a logical complement when connecting to endpoints 
> serving over https. This result in authenticating both the source and the 
> target using SSL.
> The client certificate and private key are required to complete the SSL 
> handshake. By default, the JRE will use the default {{KeyStore}} to retrieve 
> those informations. However, in some platforms such as Adobe Granite, there 
> is the ability to specify custom {{KeyStore}} based on user. For those 
> platforms, the custom {{KeyStore}} can be provided with a 
> {{javax.net.ssl.SSLContext}} which also contains a custom {{TrustStore}}.
> This issue tracks allowing to leverage certificate based authentication using 
> a custom {{javax.net.ssl.SSLContext}} in Distribution transport.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6211) Clarify AbstractJcrEventTrigger request addition strategy

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret updated SLING-6211:
--
Fix Version/s: (was: Content Distribution Core 0.2.6)
   Content Distribution Core 0.2.8

> Clarify AbstractJcrEventTrigger request addition strategy
> -
>
> Key: SLING-6211
> URL: https://issues.apache.org/jira/browse/SLING-6211
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
>
> We should clarify the logic behind 
> [AbstractJcrEventListener#addToList|https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/trigger/impl/AbstractJcrEventTrigger.java#L150]
>  as that the addition mechanism seems to rely on the last request added, 
> which seems wrong as events may come in in an unsorted manner (not consistent 
> with the order the changes they refer to were done).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [VOTE] Release Apache Sling Installer Health Checks 1.0.0

2017-03-06 Thread Oliver Lietz
On Thursday 02 March 2017 08:55:22 Oliver Lietz wrote:
> Hi,
> 
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338122

+1

O.



[jira] [Updated] (SLING-5952) Add support for configurable SO and connection timeouts

2017-03-06 Thread Timothee Maret (JIRA)

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

Timothee Maret updated SLING-5952:
--
Fix Version/s: (was: Content Distribution Core 0.2.6)
   Content Distribution Core 0.2.8

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: [RESULT] [VOTE] Release Apache Sling Content Distribution Core version 0.2.6

2017-03-06 Thread Oliver Lietz
On Monday 06 March 2017 09:29:28 Timothee Maret wrote:
> Hi,
> 
> The vote has passed with the following result :
> 
> +1 (binding): Oliver Lietz, Robert Munteanu, Daniel Klco
> +1 (non binding): Tommaso Teofili
> 
> Could a member of the @PMC please push the release to
> https://dist.apache.org/repos/dist/release/sling ?

Done.

O.

> I'll take care of the remaining steps once this is done.



[RESULT] [VOTE] Release Apache Sling Content Distribution Core version 0.2.6

2017-03-06 Thread Timothee Maret
Hi,

The vote has passed with the following result :

+1 (binding): Oliver Lietz, Robert Munteanu, Daniel Klco
+1 (non binding): Tommaso Teofili

Could a member of the @PMC please push the release to
https://dist.apache.org/repos/dist/release/sling ?
I'll take care of the remaining steps once this is done.