RE: Time for a Sling Validation 1.0.0 release
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
[ 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
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
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
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
+1
[jira] [Commented] (SLING-6614) JcrContentLoader should ignore protected nodes and properties
[ 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
[ 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
[ 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 LucazeauDate: 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 ...
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 LucazeauDate: 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
[ 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
[ 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
[ 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
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
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 Lietzwrote: > 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
+1 checked signatures and build On Mon, Mar 6, 2017 at 4:01 AM, Robert Munteanuwrote: > 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
[ 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
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
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
+1 On Mon, Mar 6, 2017 at 3:48 AM, Robert Munteanuwrote: > 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
[ 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
[ 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)
[ 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
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
[ 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
+1 regards, Karl On Mon, Mar 6, 2017 at 9:49 AM, Robert Munteanuwrote: > 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
[ 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
+1 regards, Karl On Fri, Mar 3, 2017 at 5:20 PM, Daniel Klcowrote: > +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
[ 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)
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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
+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
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
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
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
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
+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
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
[ 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
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
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
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
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.