[jira] [Resolved] (SLING-2899) Directly register script engine as event handler
[ https://issues.apache.org/jira/browse/SLING-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2899. - Resolution: Fixed Changed in revision 1489301 Directly register script engine as event handler Key: SLING-2899 URL: https://issues.apache.org/jira/browse/SLING-2899 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.0.28 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JSP 2.0.30 Currently the jsp script engine registers itself as an event handler service during activate - which complicates the code and service registration without any benefit. We can directly let DS register the engine as an event handler -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2899) Directly register script engine as event handler
Carsten Ziegeler created SLING-2899: --- Summary: Directly register script engine as event handler Key: SLING-2899 URL: https://issues.apache.org/jira/browse/SLING-2899 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.0.28 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JSP 2.0.30 Currently the jsp script engine registers itself as an event handler service during activate - which complicates the code and service registration without any benefit. We can directly let DS register the engine as an event handler -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2893) Add documentation and integration tests to verify XML parsing functionality
[ https://issues.apache.org/jira/browse/SLING-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674175#comment-13674175 ] Robert Munteanu commented on SLING-2893: Added a DOM test in http://svn.apache.org/viewvc?view=revisionrevision=1489337 Add documentation and integration tests to verify XML parsing functionality --- Key: SLING-2893 URL: https://issues.apache.org/jira/browse/SLING-2893 Project: Sling Issue Type: Test Components: Documentation, Testing Reporter: Robert Munteanu Priority: Minor We have recently been asked about XML parsing functionality on the user's list : [0] . We should have integration tests to validate the functionality and documentation to describe how it works. [0]: http://sling.markmail.org/thread/qoti6pbjx566vl5i -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2900) Avoid unnecessary classloader creation
Carsten Ziegeler created SLING-2900: --- Summary: Avoid unnecessary classloader creation Key: SLING-2900 URL: https://issues.apache.org/jira/browse/SLING-2900 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Classloader 3.1.12 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR ClassLoader 3.1.14 If a change is done through the class loader writer, the class loader is notified of that change - if no classloader exists, one is created. This can be avoided - if no classloader has been created until the change, there is no need to just yet create one -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2900) Avoid unnecessary classloader creation
[ https://issues.apache.org/jira/browse/SLING-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2900. - Resolution: Fixed Fixed by not creating the classloader for an event Avoid unnecessary classloader creation -- Key: SLING-2900 URL: https://issues.apache.org/jira/browse/SLING-2900 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Classloader 3.1.12 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR ClassLoader 3.1.14 If a change is done through the class loader writer, the class loader is notified of that change - if no classloader exists, one is created. This can be avoided - if no classloader has been created until the change, there is no need to just yet create one -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2893) Add documentation and integration tests to verify XML parsing functionality
[ https://issues.apache.org/jira/browse/SLING-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674200#comment-13674200 ] Robert Munteanu commented on SLING-2893: Added a SAX test in http://svn.apache.org/viewvc?view=revisionrevision=1489350 Add documentation and integration tests to verify XML parsing functionality --- Key: SLING-2893 URL: https://issues.apache.org/jira/browse/SLING-2893 Project: Sling Issue Type: Test Components: Documentation, Testing Reporter: Robert Munteanu Priority: Minor We have recently been asked about XML parsing functionality on the user's list : [0] . We should have integration tests to validate the functionality and documentation to describe how it works. [0]: http://sling.markmail.org/thread/qoti6pbjx566vl5i -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2901) Add robust paranoia check to detect duplicate sling.id in a cluster
[ https://issues.apache.org/jira/browse/SLING-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-2901: --- Issue Type: Improvement (was: Bug) Add robust paranoia check to detect duplicate sling.id in a cluster --- Key: SLING-2901 URL: https://issues.apache.org/jira/browse/SLING-2901 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli Follow-up of SLING-2892 which added a simple (but not robust) paranoia check for duplicate sling.id detection in a cluster. A robust check can be achieved ontop of SLING-2892 by additionally setting a 'runtimeId' property (which is a UUID assigned at activation of the HeartbeatHandler) right after activation/at first time, and checking for changes of that property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2901) Add robust paranoia check to detect duplicate sling.id in a cluster
Stefan Egli created SLING-2901: -- Summary: Add robust paranoia check to detect duplicate sling.id in a cluster Key: SLING-2901 URL: https://issues.apache.org/jira/browse/SLING-2901 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli Follow-up of SLING-2892 which added a simple (but not robust) paranoia check for duplicate sling.id detection in a cluster. A robust check can be achieved ontop of SLING-2892 by additionally setting a 'runtimeId' property (which is a UUID assigned at activation of the HeartbeatHandler) right after activation/at first time, and checking for changes of that property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2893) Add documentation and integration tests to verify XML parsing functionality
[ https://issues.apache.org/jira/browse/SLING-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-2893. Resolution: Fixed Add documentation and integration tests to verify XML parsing functionality --- Key: SLING-2893 URL: https://issues.apache.org/jira/browse/SLING-2893 Project: Sling Issue Type: Test Components: Documentation, Testing Reporter: Robert Munteanu Priority: Minor We have recently been asked about XML parsing functionality on the user's list : [0] . We should have integration tests to validate the functionality and documentation to describe how it works. [0]: http://sling.markmail.org/thread/qoti6pbjx566vl5i -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2893) Add documentation and integration tests to verify XML parsing functionality
[ https://issues.apache.org/jira/browse/SLING-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674261#comment-13674261 ] Robert Munteanu commented on SLING-2893: Updated documentation in http://svn.apache.org/viewvc?view=revisionrevision=1489379 Add documentation and integration tests to verify XML parsing functionality --- Key: SLING-2893 URL: https://issues.apache.org/jira/browse/SLING-2893 Project: Sling Issue Type: Test Components: Documentation, Testing Reporter: Robert Munteanu Priority: Minor We have recently been asked about XML parsing functionality on the user's list : [0] . We should have integration tests to validate the functionality and documentation to describe how it works. [0]: http://sling.markmail.org/thread/qoti6pbjx566vl5i -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Event Support #56
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.event/56/
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Launchpad Testing #56
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/56/changes
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #56
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/56/
Jenkins build is still unstable: sling-trunk-1.7 #56
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Updated] (SLING-2789) deploying Sling 7-SNAPSHOT on Karaf fails
[ https://issues.apache.org/jira/browse/SLING-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-2789: Attachment: SLING-2789.2013-06-04.patch - update bundles to latest releases - add discovery bundles deploying Sling 7-SNAPSHOT on Karaf fails - Key: SLING-2789 URL: https://issues.apache.org/jira/browse/SLING-2789 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Builder 7 Environment: Karaf 3.0.0.* Reporter: Oliver Lietz Assignee: Carsten Ziegeler Attachments: SLING-2789.2013-06-04.patch, SLING-2789.patch, sling-launchpad-karaf.tar.gz $ ./apache-karaf-3.0.0-SNAPSHOT/bin/start $ ssh -p 8101 karaf@localhost karaf@root() feature:install http karaf@root() feature:install webconsole karaf@root() feature:repo-add mvn:org.apache.sling/org.apache.sling.launchpad/7-SNAPSHOT/xml/features karaf@root() feature:install sling no errors on startup but JCR is nearly empty to prevent errors: - add missing org.apache.sling/org.apache.sling.launchpad.api/1.1.0 to features.xml - remove org.apache.felix/org.apache.felix.webconsole.plugins.* from features.xml - remove management from featuresBoot in org.apache.karaf.features.cfg or remove org.apache.aries.* from features.xml setting respectStartLvlDuringFeatureStartup=true and ds.factory.enabled=true does not help -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2789) deploying Sling 7-SNAPSHOT on Karaf fails
[ https://issues.apache.org/jira/browse/SLING-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674366#comment-13674366 ] Oliver Lietz commented on SLING-2789: - empty trunk/contrib/launchpad/karaf/src can be removed deploying Sling 7-SNAPSHOT on Karaf fails - Key: SLING-2789 URL: https://issues.apache.org/jira/browse/SLING-2789 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Builder 7 Environment: Karaf 3.0.0.* Reporter: Oliver Lietz Assignee: Carsten Ziegeler Attachments: SLING-2789.2013-06-04.patch, SLING-2789.patch, sling-launchpad-karaf.tar.gz $ ./apache-karaf-3.0.0-SNAPSHOT/bin/start $ ssh -p 8101 karaf@localhost karaf@root() feature:install http karaf@root() feature:install webconsole karaf@root() feature:repo-add mvn:org.apache.sling/org.apache.sling.launchpad/7-SNAPSHOT/xml/features karaf@root() feature:install sling no errors on startup but JCR is nearly empty to prevent errors: - add missing org.apache.sling/org.apache.sling.launchpad.api/1.1.0 to features.xml - remove org.apache.felix/org.apache.felix.webconsole.plugins.* from features.xml - remove management from featuresBoot in org.apache.karaf.features.cfg or remove org.apache.aries.* from features.xml setting respectStartLvlDuringFeatureStartup=true and ds.factory.enabled=true does not help -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2901) Add robust paranoia check to detect duplicate sling.id in a cluster
[ https://issues.apache.org/jira/browse/SLING-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674443#comment-13674443 ] Stefan Egli edited comment on SLING-2901 at 6/4/13 2:34 PM: Implemented. Javadoc of discovery.api (DiscoveryService) adjusted. The discovery.impl sends out a TOPOLOGY_CHANGING event before stopping its bundle on detection of a duplicate sling.id in a cluster. was (Author: egli): The discovery.impl sends out a TOPOLOGY_CHANGING event before stopping its bundle on detection of a duplicate sling.id in a cluster. Add robust paranoia check to detect duplicate sling.id in a cluster --- Key: SLING-2901 URL: https://issues.apache.org/jira/browse/SLING-2901 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli Follow-up of SLING-2892 which added a simple (but not robust) paranoia check for duplicate sling.id detection in a cluster. A robust check can be achieved ontop of SLING-2892 by additionally setting a 'runtimeId' property (which is a UUID assigned at activation of the HeartbeatHandler) right after activation/at first time, and checking for changes of that property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2901) Add robust paranoia check to detect duplicate sling.id in a cluster
[ https://issues.apache.org/jira/browse/SLING-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-2901. Resolution: Fixed Add robust paranoia check to detect duplicate sling.id in a cluster --- Key: SLING-2901 URL: https://issues.apache.org/jira/browse/SLING-2901 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli Follow-up of SLING-2892 which added a simple (but not robust) paranoia check for duplicate sling.id detection in a cluster. A robust check can be achieved ontop of SLING-2892 by additionally setting a 'runtimeId' property (which is a UUID assigned at activation of the HeartbeatHandler) right after activation/at first time, and checking for changes of that property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2901) Add robust paranoia check to detect duplicate sling.id in a cluster
[ https://issues.apache.org/jira/browse/SLING-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674443#comment-13674443 ] Stefan Egli commented on SLING-2901: The discovery.impl sends out a TOPOLOGY_CHANGING event before stopping its bundle on detection of a duplicate sling.id in a cluster. Add robust paranoia check to detect duplicate sling.id in a cluster --- Key: SLING-2901 URL: https://issues.apache.org/jira/browse/SLING-2901 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli Follow-up of SLING-2892 which added a simple (but not robust) paranoia check for duplicate sling.id detection in a cluster. A robust check can be achieved ontop of SLING-2892 by additionally setting a 'runtimeId' property (which is a UUID assigned at activation of the HeartbeatHandler) right after activation/at first time, and checking for changes of that property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2822) Extensible Sling system health checking tool
[ https://issues.apache.org/jira/browse/SLING-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674474#comment-13674474 ] Bertrand Delacretaz commented on SLING-2822: In http://svn.apache.org/r1489464 , executing rules from the repository is limited to admin users (based on having add_node permission at /libs) Extensible Sling system health checking tool Key: SLING-2822 URL: https://issues.apache.org/jira/browse/SLING-2822 Project: Sling Issue Type: Improvement Components: Testing Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: nodes.json, nodes.json, setup.bash I have created a prototype at https://github.com/bdelacretaz/muppet-prototype that we might want to move to our contrib folder. Muppet (it's like a Puppet, but different (*)) allows you to check the health of a system by defining rules that (out of the box) verify things like the presence of specific OSGi bundles, JMX MBeans values, JUnit tests execution (including scriptable ones thanks to the Sling testing tools), correct disabling of default Sling credentials, etc. New rule types can be defined by adding RuleBuilder OSGi services, there are several examples in this initial code. I'll add a how-to for this initial version here. Known issues are: -The output does not indicate the value that causes a rule to fail -The servlet output is not JSON yet -Tags on rules would be nice to be able to run just the performance or security rules for example -A rule for checking OSGi configuration parameters would be useful. (*) credits to Joerg Hoh for that one, as well as inspiration in https://github.com/joerghoh/cq5-healthcheck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2780) Make ResourceMetadata read-only when delivered to client code
[ https://issues.apache.org/jira/browse/SLING-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674491#comment-13674491 ] Alexander Klimetschek commented on SLING-2780: -- With this change and a custom, wrapping ResourceProvider I now get an exception ResourceMetadata is locked when requesting that resource (/overlay/foo) in a GET request (see below). The exception happens during sling's request initialization phase. My custom provider does wrap resources from another location/provider, which are accessed through the ResourceResolver. The safe and right solution seems to wrap the metadata object: ResourceMetadata metadata = new ResourceMetadata(); metadata.putAll(getResource().getResourceMetadata()); But I just want to point out that this might break some existing resource providers. And the question is if resource decorators are safe. GET /overlay/foo HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught Throwable java.lang.UnsupportedOperationException: ResourceMetadata is locked at org.apache.sling.api.resource.ResourceMetadata.checkReadOnly(ResourceMetadata.java:310) at org.apache.sling.api.resource.ResourceMetadata.put(ResourceMetadata.java:322) at org.apache.sling.api.resource.ResourceMetadata.setResolutionPath(ResourceMetadata.java:254) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:916) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getChildInternal(ResourceResolverImpl.java:872) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolveInternal(ResourceResolverImpl.java:819) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolve(ResourceResolverImpl.java:319) at org.apache.sling.engine.impl.request.RequestData.initResource(RequestData.java:208) at org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:140) at org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206) Make ResourceMetadata read-only when delivered to client code - Key: SLING-2780 URL: https://issues.apache.org/jira/browse/SLING-2780 Project: Sling Issue Type: New Feature Components: API, ResourceResolver Affects Versions: API 2.3.0, Resource Resolver 1.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.4.0, Resource Resolver 1.0.6 As recently discussed in the mailing list, ResourceMetadata is an object which provides additional metadata information about a resource but is not intended to be changed by client code. As ResourceMetadata extends from (Hash)Map it is read/write by default and might potentially be changed by client code. We should update the API docs that this object is read-only and also enforce it in our implementation. It seems so far no one is changing the ResourceMetadata after it has left the resource resolver, therefore we can make it read-only after it is returned by the resource resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1683
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1683/changes
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1683
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1683/changes
Jenkins build became unstable: sling-trunk-1.6 #1683
See https://builds.apache.org/job/sling-trunk-1.6/1683/changes
[jira] [Commented] (SLING-2822) Extensible Sling system health checking tool
[ https://issues.apache.org/jira/browse/SLING-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13674512#comment-13674512 ] Bertrand Delacretaz commented on SLING-2822: JSON output works in http://svn.apache.org/r1489484 Extensible Sling system health checking tool Key: SLING-2822 URL: https://issues.apache.org/jira/browse/SLING-2822 Project: Sling Issue Type: Improvement Components: Testing Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: nodes.json, nodes.json, setup.bash I have created a prototype at https://github.com/bdelacretaz/muppet-prototype that we might want to move to our contrib folder. Muppet (it's like a Puppet, but different (*)) allows you to check the health of a system by defining rules that (out of the box) verify things like the presence of specific OSGi bundles, JMX MBeans values, JUnit tests execution (including scriptable ones thanks to the Sling testing tools), correct disabling of default Sling credentials, etc. New rule types can be defined by adding RuleBuilder OSGi services, there are several examples in this initial code. I'll add a how-to for this initial version here. Known issues are: -The output does not indicate the value that causes a rule to fail -The servlet output is not JSON yet -Tags on rules would be nice to be able to run just the performance or security rules for example -A rule for checking OSGi configuration parameters would be useful. (*) credits to Joerg Hoh for that one, as well as inspiration in https://github.com/joerghoh/cq5-healthcheck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Disabling flaky tests
I used to agree as well, but my opinion is now more nuanced. I've experienced projects where a test keeps failing day after day, and after a while developers stop looking at the test results with the same level of discipline. Perhaps Sling is small enough (and the developers are pro-active enough) that this isn't an issue. But it certainly is on some other, larger, more disperse projects (such as CQ). In those, moving a failing test to an issue (which can be assigned to an individual) can produce better results than everyone simply getting used to the build being red. Cheers, Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 03 June 2013 07:01 To: dev@sling.apache.org Subject: Re: Disabling flaky tests I agree as well, especially for the error handling as this is partially not a problem of the test but really a bug in Sling - we have an issue for that, it just needs to be done :) Carsten 2013/6/3 Felix Meschberger fmesc...@adobe.com I agree here: Disabling the test and having an issue keeps the build green but bears the danger of forgetting about it ... Regards Felix Am 02.06.2013 um 16:04 schrieb Eric Norman: Personally, I'm not a big fan of hiding flaky/failing tests since it tends to remove some of the motivation to stabilize/fix them in a timely manner. That's my 2 cents. Regards, Eric On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu romb...@apache.org wrote: Hi, It seems that the ErrorHandlingTest fails sporadically when run inside a full maven build. I've tried locating the root cause for a couple of hours but failed. For this test, and for future flaky/failing tests, I suggest that we 1. Create an issue for the failing test 2. Disable the test and mark it with the issue key 3. Re-enable the test when it is stable/passing ( which may be considerably later than step 2) 4. Close the issue after the test is re-enabled This has the advantage of keeping the build green and making it easier to find regressions since a failing or unstable build will actually mean something. What do you think? Robert -- Carsten Ziegeler cziege...@apache.org
Re: Disabling flaky tests
I would agree if the jenkins we have would be stable; i have the feeling that a lot of build failures on that instance are simply because of some problems of the build server itself. I tried to chased too many times such issues. For example, right now, every day we get build errors reported in some modules while at the next day they pass - without any changes at all. So I think the first step is to have a stable build env But I'm fine with any direction as long as we fix known bugs before a release Carsten 2013/6/4 Jeff Young j...@adobe.com I used to agree as well, but my opinion is now more nuanced. I've experienced projects where a test keeps failing day after day, and after a while developers stop looking at the test results with the same level of discipline. Perhaps Sling is small enough (and the developers are pro-active enough) that this isn't an issue. But it certainly is on some other, larger, more disperse projects (such as CQ). In those, moving a failing test to an issue (which can be assigned to an individual) can produce better results than everyone simply getting used to the build being red. Cheers, Jeff. -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 03 June 2013 07:01 To: dev@sling.apache.org Subject: Re: Disabling flaky tests I agree as well, especially for the error handling as this is partially not a problem of the test but really a bug in Sling - we have an issue for that, it just needs to be done :) Carsten 2013/6/3 Felix Meschberger fmesc...@adobe.com I agree here: Disabling the test and having an issue keeps the build green but bears the danger of forgetting about it ... Regards Felix Am 02.06.2013 um 16:04 schrieb Eric Norman: Personally, I'm not a big fan of hiding flaky/failing tests since it tends to remove some of the motivation to stabilize/fix them in a timely manner. That's my 2 cents. Regards, Eric On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu romb...@apache.org wrote: Hi, It seems that the ErrorHandlingTest fails sporadically when run inside a full maven build. I've tried locating the root cause for a couple of hours but failed. For this test, and for future flaky/failing tests, I suggest that we 1. Create an issue for the failing test 2. Disable the test and mark it with the issue key 3. Re-enable the test when it is stable/passing ( which may be considerably later than step 2) 4. Close the issue after the test is re-enabled This has the advantage of keeping the build green and making it easier to find regressions since a failing or unstable build will actually mean something. What do you think? Robert -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #57
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing-war/57/
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #57
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/57/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #57
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/57/
Jenkins build is still unstable: sling-trunk-1.7 #57
See https://builds.apache.org/job/sling-trunk-1.7/changes
