[jira] [Assigned] (SLING-3228) PostServletPrivilegesUpdateTest integration test fails with Oak, needs test categories

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu reassigned SLING-3228:
--

Assignee: Robert Munteanu

> PostServletPrivilegesUpdateTest integration test fails with Oak, needs test 
> categories
> --
>
> Key: SLING-3228
> URL: https://issues.apache.org/jira/browse/SLING-3228
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>Priority: Minor
>  Labels: sling-IT
>
> The PostServletPrivilegesUpdateTest test fails on Oak, it expects a property 
> added event that Oak doesn't supply.
> This is a good opportunity to implement the SLING-3151 test categories, we 
> can then keep both tests so as to document the subtle differences between Oak 
> and Jackrabbit when it comes to JCR events.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-3228) PostServletPrivilegesUpdateTest integration test fails with Oak, needs test categories

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-3228:


Actually the problem is with the test, or rather with the Davex remoting not 
being able to deliver observation events - see OAK-6583.

> PostServletPrivilegesUpdateTest integration test fails with Oak, needs test 
> categories
> --
>
> Key: SLING-3228
> URL: https://issues.apache.org/jira/browse/SLING-3228
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> The PostServletPrivilegesUpdateTest test fails on Oak, it expects a property 
> added event that Oak doesn't supply.
> This is a good opportunity to implement the SLING-3151 test categories, we 
> can then keep both tests so as to document the subtle differences between Oak 
> and Jackrabbit when it comes to JCR events.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7080) Update options and versions to latest features

2017-08-23 Thread Oliver Lietz (JIRA) 

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

Oliver Lietz commented on SLING-7080:
-

[r1805968|https://svn.apache.org/r1805968]

> Update options and versions to latest features
> --
>
> Key: SLING-7080
> URL: https://issues.apache.org/jira/browse/SLING-7080
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing PaxExam 0.0.6
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-4996) FullTextIndexingTest needs very long (60 seconds) timeout for Oak

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-4996:


After restoring the test ( SLING-7081 ) the test finished in 10-15 seconds for 
3 passes, so that's 3-5 seconds per individual test.

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.653 sec - in 
org.apache.sling.launchpad.webapp.integrationtest.indexing.FullTextIndexingTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.051 sec - in 
org.apache.sling.launchpad.webapp.integrationtest.indexing.FullTextIndexingTest

In [r1805959|https://svn.apache.org/r1805959] I've set the timeout to 15 
seconds per test, should be more than enough.

> FullTextIndexingTest needs very long (60 seconds) timeout for Oak
> -
>
> Key: SLING-4996
> URL: https://issues.apache.org/jira/browse/SLING-4996
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-it
> Fix For: Launchpad Testing 9
>
>
> I had to increase the timeout to 60 seconds in the 
> {{launchpad/integration-tests/.../FullTextIndexingTest}} to make it pass 
> reliably with Oak on Jenkins.
> I suspect the Oak indexes are not always ready when the test runs: the error 
> log shows "org.apache.jackrabbit.oak.plugins.index.IndexUpdate Indexing 
> report" messages after the test runs, which I suppose signals the end of an 
> indexing task.
> We should find out how to take this into account in the tests, either wait 
> for all required indexes to be ready before starting our tests, or having a 
> way to find out whether a specific set of indexes is ready before starting a 
> specific test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-4996) FullTextIndexingTest needs very long (60 seconds) timeout for Oak

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu resolved SLING-4996.

   Resolution: Fixed
Fix Version/s: Launchpad Testing 9

> FullTextIndexingTest needs very long (60 seconds) timeout for Oak
> -
>
> Key: SLING-4996
> URL: https://issues.apache.org/jira/browse/SLING-4996
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>Priority: Minor
>  Labels: sling-it
> Fix For: Launchpad Testing 9
>
>
> I had to increase the timeout to 60 seconds in the 
> {{launchpad/integration-tests/.../FullTextIndexingTest}} to make it pass 
> reliably with Oak on Jenkins.
> I suspect the Oak indexes are not always ready when the test runs: the error 
> log shows "org.apache.jackrabbit.oak.plugins.index.IndexUpdate Indexing 
> report" messages after the test runs, which I suppose signals the end of an 
> indexing task.
> We should find out how to take this into account in the tests, either wait 
> for all required indexes to be ready before starting our tests, or having a 
> way to find out whether a specific set of indexes is ready before starting a 
> specific test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-4996) FullTextIndexingTest needs very long (60 seconds) timeout for Oak

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu reassigned SLING-4996:
--

Assignee: Robert Munteanu

> FullTextIndexingTest needs very long (60 seconds) timeout for Oak
> -
>
> Key: SLING-4996
> URL: https://issues.apache.org/jira/browse/SLING-4996
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>Priority: Minor
>  Labels: sling-it
> Fix For: Launchpad Testing 9
>
>
> I had to increase the timeout to 60 seconds in the 
> {{launchpad/integration-tests/.../FullTextIndexingTest}} to make it pass 
> reliably with Oak on Jenkins.
> I suspect the Oak indexes are not always ready when the test runs: the error 
> log shows "org.apache.jackrabbit.oak.plugins.index.IndexUpdate Indexing 
> report" messages after the test runs, which I suppose signals the end of an 
> indexing task.
> We should find out how to take this into account in the tests, either wait 
> for all required indexes to be ready before starting our tests, or having a 
> way to find out whether a specific set of indexes is ready before starting a 
> specific test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7081) Restore FullTextIndexingTest

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu resolved SLING-7081.

Resolution: Fixed

Verified passing on Jenkins

> Restore FullTextIndexingTest
> 
>
> Key: SLING-7081
> URL: https://issues.apache.org/jira/browse/SLING-7081
> Project: Sling
>  Issue Type: Test
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Testing 9
>
>
> Test was removed in [r1797403|https://svn.apache.org/r1797403] for 
> SLING-6928, but we should restore it and make it not use the query servlet 
> anymore.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-5803) FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-5803:


Test is ignored again in [r1805958|https://svn.apache.org/r1805958]

> FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins
> --
>
> Key: SLING-5803
> URL: https://issues.apache.org/jira/browse/SLING-5803
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Andrei Dulvac
>Priority: Minor
>  Labels: sling-IT
>
> These tests are consistently failing on Jenkins as in [1] for example:
> * FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists
> * FilterRuleExcludeCategoryTest.testExcludedCategoryExists
> both with "java.lang.AssertionError: Test should be Ignored"
> Andrei, as you wrote those tests, could you have a look?
> [1] https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/4145/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-5803) FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-5803:


Nope, still fails on Jenkins - 
https://builds.apache.org/view/S-Z/view/Sling/job/sling-testing-junit-rules-1.8/13/org.apache.sling$org.apache.sling.testing.rules/testReport/org.apache.sling.testing.junit.rules.util.filterrule/FilterRuleExcludeCategoryIgnoreIfTest/testExcludedCategoryExists/

And still passes locally, no idea what is going on.

> FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins
> --
>
> Key: SLING-5803
> URL: https://issues.apache.org/jira/browse/SLING-5803
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Andrei Dulvac
>Priority: Minor
>  Labels: sling-IT
>
> These tests are consistently failing on Jenkins as in [1] for example:
> * FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists
> * FilterRuleExcludeCategoryTest.testExcludedCategoryExists
> both with "java.lang.AssertionError: Test should be Ignored"
> Andrei, as you wrote those tests, could you have a look?
> [1] https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/4145/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7081) Restore FullTextIndexingTest

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-7081:


Test restored in [r1805955|https://svn.apache.org/r1805955], with a custom 
query servlet added.

> Restore FullTextIndexingTest
> 
>
> Key: SLING-7081
> URL: https://issues.apache.org/jira/browse/SLING-7081
> Project: Sling
>  Issue Type: Test
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Testing 9
>
>
> Test was removed in [r1797403|https://svn.apache.org/r1797403] for 
> SLING-6928, but we should restore it and make it not use the query servlet 
> anymore.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7081) Restore FullTextIndexingTest

2017-08-23 Thread Robert Munteanu (JIRA) 
Robert Munteanu created SLING-7081:
--

 Summary: Restore FullTextIndexingTest
 Key: SLING-7081
 URL: https://issues.apache.org/jira/browse/SLING-7081
 Project: Sling
  Issue Type: Test
  Components: Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Launchpad Testing 9


Test was removed in [r1797403|https://svn.apache.org/r1797403] for SLING-6928, 
but we should restore it and make it not use the query servlet anymore.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-4996) FullTextIndexingTest needs very long (60 seconds) timeout for Oak

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-4996:


Note that the test was removed in [r1797403|https://svn.apache.org/r1797403] 
for SLING-6928, presumably as it was using the servlets.compat bundle to 
verifying the test results. However, this should be restored.

> FullTextIndexingTest needs very long (60 seconds) timeout for Oak
> -
>
> Key: SLING-4996
> URL: https://issues.apache.org/jira/browse/SLING-4996
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-it
>
> I had to increase the timeout to 60 seconds in the 
> {{launchpad/integration-tests/.../FullTextIndexingTest}} to make it pass 
> reliably with Oak on Jenkins.
> I suspect the Oak indexes are not always ready when the test runs: the error 
> log shows "org.apache.jackrabbit.oak.plugins.index.IndexUpdate Indexing 
> report" messages after the test runs, which I suppose signals the end of an 
> indexing task.
> We should find out how to take this into account in the tests, either wait 
> for all required indexes to be ready before starting our tests, or having a 
> way to find out whether a specific set of indexes is ready before starting a 
> specific test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-5803) FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-5803:


Re-enabled the test in [r1805950|https://svn.apache.org/r1805950], hoping that 
switching to per-module build job fixes the problem.

> FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins
> --
>
> Key: SLING-5803
> URL: https://issues.apache.org/jira/browse/SLING-5803
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Andrei Dulvac
>Priority: Minor
>  Labels: sling-IT
>
> These tests are consistently failing on Jenkins as in [1] for example:
> * FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists
> * FilterRuleExcludeCategoryTest.testExcludedCategoryExists
> both with "java.lang.AssertionError: Test should be Ignored"
> Andrei, as you wrote those tests, could you have a look?
> [1] https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/4145/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6417) Flaky test: FiltersTest.testCounters

2017-08-23 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu resolved SLING-6417.

Resolution: Cannot Reproduce

No longer an issue


> Flaky test: FiltersTest.testCounters
> 
>
> Key: SLING-6417
> URL: https://issues.apache.org/jira/browse/SLING-6417
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Robert Munteanu
>  Labels: sling-IT
>
> FiltersTest.testCounter failed 6 of the last 10 runs according to the Test 
> Results Analyzer ( 
> https://builds.apache.org/job/sling-launchpad-testing-1.8/test_results_analyzer/)
>  
> Passed: #304, #308, #310, #311
> Failed: #305, #306, #307, #309, #312, #313
> The error is always
> {noformat}junit.framework.AssertionFailedError: 
> http://localhost:41601/index.html expected:<200> but was:<404>
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.TestCase.assertEquals(TestCase.java:401)
>   at 
> org.apache.sling.commons.testing.integration.HttpTestBase.assertHttpStatus(HttpTestBase.java:363)
>   at 
> org.apache.sling.commons.testing.integration.HttpTestBase.assertHttpStatus(HttpTestBase.java:374)
>   at 
> org.apache.sling.launchpad.webapp.integrationtest.FiltersTest.testCounters(FiltersTest.java:26){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.0

2017-08-23 Thread Daniel Klco 
+1

On Wed, Aug 23, 2017 at 9:21 AM, Stefan Seifert 
wrote:

> +1
>

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.8

2017-08-23 Thread Daniel Klco 
+1

On Wed, Aug 23, 2017 at 9:18 AM, Stefan Seifert 
wrote:

> +1
>
>

[jira] [Comment Edited] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

2017-08-23 Thread Alex Deparvu (JIRA) 

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

Alex Deparvu edited comment on SLING-7074 at 8/23/17 4:42 PM:
--

this seems a bit more complicated than I though. I opened a few pull requests 
on the rrd4j project hoping things will be nicer looking, but I'm not sure what 
the eta could be [0] [1]. I'll probably submit PRs also but wanted to see what 
the maintainers think first.

The lack of parameter verification on the config manager is tough to work with. 
Basically there should be no rrd store started if
* step is <=0 (I can use the default value here)
* no datasources defined (err is "No RRD datasource specified. At least one is 
needed.")
* no archives defined (err is "No RRD archive specified. At least one is 
needed.")
and all of these are IllegalArgumentExceptions coming from rrd with no way to 
pass them to the config manager except log some sort of warning in the logs 
which might not be enough.

I think I'd go with stopping and not starting any rrd store if there's any 
illegal params. the simplest way I see is have the builder return null in this 
case.
[~mreutegg] thoughts?


https://github.com/rrd4j/rrd4j/issues/104
https://github.com/rrd4j/rrd4j/issues/105


was (Author: alex.parvulescu):
this seems a bit more complicated than I though. I opened a few pull requests 
on the rrd4j project hoping things will be nicer looking, but I'm not sure what 
the eta could be [0] [1]. I'll probably submit PRs also but wanted to see what 
the maintainers think first.

The lack of parameter verification on the config manager is tough to work with. 
Basically there should be no rrd store started if
* step is <=0 (I can use the default value here)
* no datasources defined (err is "No RRD datasource specified. At least one is 
needed.")
* no archives defined (err is "No RRD archive specified. At least one is 
needed.")
and all of these are IllegalArgumentExceptions coming from rrd with no way to 
pass them to the config manager except log some sort of warning in the logs 
which might not be enough.

I think I'd go with stopping and not starting any rrd store if there's any 
illegal params. [~mreutegg] thoughts?


https://github.com/rrd4j/rrd4j/issues/104
https://github.com/rrd4j/rrd4j/issues/105

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

2017-08-23 Thread Alex Deparvu (JIRA) 

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

Alex Deparvu commented on SLING-7074:
-

this seems a bit more complicated than I though. I opened a few pull requests 
on the rrd4j project hoping things will be nicer looking, but I'm not sure what 
the eta could be [0] [1]. I'll probably submit PRs also but wanted to see what 
the maintainers think first.

The lack of parameter verification on the config manager is tough to work with. 
Basically there should be no rrd store started if
* step is <=0 (I can use the default value here)
* no datasources defined (err is "No RRD datasource specified. At least one is 
needed.")
* no archives defined (err is "No RRD archive specified. At least one is 
needed.")
and all of these are IllegalArgumentExceptions coming from rrd with no way to 
pass them to the config manager except log some sort of warning in the logs 
which might not be enough.

I think I'd go with not stopping and starting any rrd store if there's any 
illegal params. [~mreutegg] thoughts?


https://github.com/rrd4j/rrd4j/issues/104
https://github.com/rrd4j/rrd4j/issues/105

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

2017-08-23 Thread Alex Deparvu (JIRA) 

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

Alex Deparvu edited comment on SLING-7074 at 8/23/17 4:41 PM:
--

this seems a bit more complicated than I though. I opened a few pull requests 
on the rrd4j project hoping things will be nicer looking, but I'm not sure what 
the eta could be [0] [1]. I'll probably submit PRs also but wanted to see what 
the maintainers think first.

The lack of parameter verification on the config manager is tough to work with. 
Basically there should be no rrd store started if
* step is <=0 (I can use the default value here)
* no datasources defined (err is "No RRD datasource specified. At least one is 
needed.")
* no archives defined (err is "No RRD archive specified. At least one is 
needed.")
and all of these are IllegalArgumentExceptions coming from rrd with no way to 
pass them to the config manager except log some sort of warning in the logs 
which might not be enough.

I think I'd go with stopping and not starting any rrd store if there's any 
illegal params. [~mreutegg] thoughts?


https://github.com/rrd4j/rrd4j/issues/104
https://github.com/rrd4j/rrd4j/issues/105


was (Author: alex.parvulescu):
this seems a bit more complicated than I though. I opened a few pull requests 
on the rrd4j project hoping things will be nicer looking, but I'm not sure what 
the eta could be [0] [1]. I'll probably submit PRs also but wanted to see what 
the maintainers think first.

The lack of parameter verification on the config manager is tough to work with. 
Basically there should be no rrd store started if
* step is <=0 (I can use the default value here)
* no datasources defined (err is "No RRD datasource specified. At least one is 
needed.")
* no archives defined (err is "No RRD archive specified. At least one is 
needed.")
and all of these are IllegalArgumentExceptions coming from rrd with no way to 
pass them to the config manager except log some sort of warning in the logs 
which might not be enough.

I think I'd go with not stopping and starting any rrd store if there's any 
illegal params. [~mreutegg] thoughts?


https://github.com/rrd4j/rrd4j/issues/104
https://github.com/rrd4j/rrd4j/issues/105

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7080) Update options and versions to latest features

2017-08-23 Thread Oliver Lietz (JIRA) 
Oliver Lietz created SLING-7080:
---

 Summary: Update options and versions to latest features
 Key: SLING-7080
 URL: https://issues.apache.org/jira/browse/SLING-7080
 Project: Sling
  Issue Type: Task
  Components: Testing
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Testing PaxExam 0.0.6






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: [VOTE] Release Apache Sling Models API 1.3.6, Implementation 1.4.4 and Jackson Exporter 1.0.8

2017-08-23 Thread Stefan Seifert 
+1

[jira] [Resolved] (SLING-7079) Update Oak to 1.6.4

2017-08-23 Thread Oliver Lietz (JIRA) 

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

Oliver Lietz resolved SLING-7079.
-
Resolution: Done

[r1805921|https://svn.apache.org/r1805921]
[r1805922|https://svn.apache.org/r1805922]

> Update Oak to 1.6.4
> ---
>
> Key: SLING-7079
> URL: https://issues.apache.org/jira/browse/SLING-7079
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, JCR Oak Server 1.1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7078) Update Jackrabbit to 2.14.2

2017-08-23 Thread Oliver Lietz (JIRA) 

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

Oliver Lietz resolved SLING-7078.
-
Resolution: Done

[r1805914|https://svn.apache.org/r1805914]
[r1805915|https://svn.apache.org/r1805915]
[r1805917|https://svn.apache.org/r1805917]
[r1805918|https://svn.apache.org/r1805918]
[r1805919|https://svn.apache.org/r1805919]
[r1805920|https://svn.apache.org/r1805920]

> Update Jackrabbit to 2.14.2
> ---
>
> Key: SLING-7078
> URL: https://issues.apache.org/jira/browse/SLING-7078
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Karaf, Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
> Commons Testing 2.1.2, JCR Davex 1.3.10, JCR Webdav 2.3.10, JCR Oak Server 
> 1.1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7079) Update Oak to 1.6.4

2017-08-23 Thread Oliver Lietz (JIRA) 
Oliver Lietz created SLING-7079:
---

 Summary: Update Oak to 1.6.4
 Key: SLING-7079
 URL: https://issues.apache.org/jira/browse/SLING-7079
 Project: Sling
  Issue Type: Task
  Components: JCR, Karaf
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, JCR Oak Server 1.1.6






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7078) Update Jackrabbit to 2.14.2

2017-08-23 Thread Oliver Lietz (JIRA) 
Oliver Lietz created SLING-7078:
---

 Summary: Update Jackrabbit to 2.14.2
 Key: SLING-7078
 URL: https://issues.apache.org/jira/browse/SLING-7078
 Project: Sling
  Issue Type: Task
  Components: JCR, Karaf, Testing
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
Commons Testing 2.1.2, JCR Davex 1.3.10, JCR Webdav 2.3.10, JCR Oak Server 1.1.6






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE] Release Apache Sling Models API 1.3.6, Implementation 1.4.4 and Jackson Exporter 1.0.8

2017-08-23 Thread Justin Edelson 
Hi,

We solved 4 issues in these releases:
https://issues.apache.org/jira/projects/SLING/versions/12341121
https://issues.apache.org/jira/projects/SLING/versions/12340558
https://issues.apache.org/jira/projects/SLING/versions/12338830

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

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 1773 /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.

[jira] [Updated] (SLING-7077) Reduce size of RRD4J metrics reporter

2017-08-23 Thread Marcel Reutegger (JIRA) 

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

Marcel Reutegger updated SLING-7077:

Attachment: SLING-7077.patch

Proposed changes in [^SLING-7077.patch] reduces the bundle size from 695K to 
296K.

> Reduce size of RRD4J metrics reporter
> -
>
> Key: SLING-7077
> URL: https://issues.apache.org/jira/browse/SLING-7077
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7077.patch
>
>
> The RRD4J library contains graph functionality and fonts not needed by the 
> reporter. These should be excluded from the bundle. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7077) Reduce size of RRD4J metrics reporter

2017-08-23 Thread Marcel Reutegger (JIRA) 
Marcel Reutegger created SLING-7077:
---

 Summary: Reduce size of RRD4J metrics reporter
 Key: SLING-7077
 URL: https://issues.apache.org/jira/browse/SLING-7077
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Marcel Reutegger
Priority: Minor
 Fix For: Commons Metrics RRD4J 1.0.0


The RRD4J library contains graph functionality and fonts not needed by the 
reporter. These should be excluded from the bundle. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7076) traversing pipe

2017-08-23 Thread Nicolas Peltier (JIRA) 
Nicolas Peltier created SLING-7076:
--

 Summary: traversing pipe
 Key: SLING-7076
 URL: https://issues.apache.org/jira/browse/SLING-7076
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Pipes 0.0.10
Reporter: Nicolas Peltier


add a pipe traversing current resource tree, allowing to traverse node or node 
& properties. Adding traversal priority (depth or breadth first) 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: [VOTE] Release Apache Sling Commons Scheduler 2.7.0

2017-08-23 Thread Stefan Seifert 
+1

RE: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.8

2017-08-23 Thread Stefan Seifert 
+1

[jira] [Assigned] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

2017-08-23 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz reassigned SLING-6423:
--

Assignee: Timothee Maret  (was: Bertrand Delacretaz)

Reassigning to Tim who apparently has time to work in this in the next few days.

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7075) Inherited public fields cannot be accessed directly in HTL

2017-08-23 Thread Radu Cotescu (JIRA) 
Radu Cotescu created SLING-7075:
---

 Summary: Inherited public fields cannot be accessed directly in HTL
 Key: SLING-7075
 URL: https://issues.apache.org/jira/browse/SLING-7075
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting HTL Engine 1.0.20, Scripting Sightly Engine 
1.0.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL Engine 1.0.38


Inherited public fields cannot be accessed directly in HTL, due to how object 
properties resolution is implemented in 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java#L293.

When solving {{Fields}} the {{Field#getField}} method should be used instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7075) Inherited public fields cannot be accessed directly in HTL

2017-08-23 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu updated SLING-7075:

Description: 
Inherited public fields for a Java use-class cannot be accessed directly in 
HTL, due to how object properties resolution is implemented in 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java#L293.

When solving {{Fields}} the {{Field#getField}} method should be used instead.

  was:
Inherited public fields cannot be accessed directly in HTL, due to how object 
properties resolution is implemented in 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java#L293.

When solving {{Fields}} the {{Field#getField}} method should be used instead.


> Inherited public fields cannot be accessed directly in HTL
> --
>
> Key: SLING-7075
> URL: https://issues.apache.org/jira/browse/SLING-7075
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine 
> 1.0.20
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.38
>
>
> Inherited public fields for a Java use-class cannot be accessed directly in 
> HTL, due to how object properties resolution is implemented in 
> https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java#L293.
> When solving {{Fields}} the {{Field#getField}} method should be used instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)