[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647559#comment-14647559 ] Carsten Ziegeler commented on SLING-4895: - 1. Yes, that's true - this can in theory happen, but I thought it's too unlikely :) 2. I guess this can be solved/synced somehow Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647535#comment-14647535 ] Carsten Ziegeler commented on SLING-4895: - [~mpetria] Yes, duplicate mappings are valid for the reason you describe :) Ok, looking forward to your patch and then we can do a beauty contest (though I fear, mine will loose) Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647550#comment-14647550 ] Marius Petria commented on SLING-4895: -- I am afraid it is a bit harder than I thought initially to prevent double registration :). However even for you version I have some questions. 1. unregisterMapping does not remove the mapping from unprocessed mappings 2. what happens if registerMapping and unregisterMapping execute concurrently for the same mapping (modulo equals). It can happen that registerMapping just puts an incomplete placeholder that unregisterMapping will pick it up bringing the useCount to -1. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647514#comment-14647514 ] Marius Petria commented on SLING-4895: -- [~cziegeler] I'll try to understand the things a little better. Are duplicate mappings a valid case? It appears to be so, because two amendment configs can have different service.ranking and the reason for that it is probably to be able to override a mapping providing a different username. Hence the identity of a mapping is given by the serviceName and subServiceName, and this means the current compareTo method of Mapping is wrong and should not take into account the userName. Compared to my version I think what you do with useCount and unprocessedRegistrations was done by eliminating duplicates of Mappings using sorted sets. The major difference is that in my version you could end up registering a service concurrently and hence you need to unregister. So I think doing something similar to what you do with a placeholder registration makes sense. I will update my patch to behave similarly and let's decide then which way to go :). Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-4895: - Attachment: SLING-4895.1.diff I created another patch that uses a placeholder registration object and then delegates the registrations and unregistrations outside the synched zones. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.1.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4919) Require configuration for webdav related services
[ https://issues.apache.org/jira/browse/SLING-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4919. - Resolution: Fixed Require configuration for webdav related services - Key: SLING-4919 URL: https://issues.apache.org/jira/browse/SLING-4919 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Webdav 2.2.2, JCR DavEx 1.2.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Webdav 2.2.4, JCR DavEx 1.2.4 In order to easier enable webdav/davex support, we should make those components require a configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4919) Require configuration for webdav related services
[ https://issues.apache.org/jira/browse/SLING-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647833#comment-14647833 ] Bertrand Delacretaz commented on SLING-4919: Won't this break integration tests? Or did you add the necessary configs so that the WebDAV service is still enabled by default in the launchpad? Require configuration for webdav related services - Key: SLING-4919 URL: https://issues.apache.org/jira/browse/SLING-4919 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Webdav 2.2.2, JCR DavEx 1.2.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Webdav 2.2.4, JCR DavEx 1.2.4 In order to easier enable webdav/davex support, we should make those components require a configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4919) Require configuration for webdav related services
Carsten Ziegeler created SLING-4919: --- Summary: Require configuration for webdav related services Key: SLING-4919 URL: https://issues.apache.org/jira/browse/SLING-4919 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR DavEx 1.2.2, JCR Webdav 2.2.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Webdav 2.2.4, JCR DavEx 1.2.4 In order to easier enable webdav/davex support, we should make those components require a configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Content Distribution Core version 0.1.6
PS: just noted that this includes org.apache.sling.distribution.sample-0.1.2 - I assume this is intentional? Cheers, Stefan On 7/29/15 5:09 PM, Stefan Egli stefane...@apache.org wrote: +1 Cheers, Stefan On 7/29/15 4:25 PM, Marius Petria mpet...@adobe.com wrote: Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12333012 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12323405 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1304/ 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 1304 /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.
Re: [VOTE] Release Apache Sling Content Distribution Core version 0.1.6
On Thu, 2015-07-30 at 09:13 +0200, Stefan Egli wrote: PS: just noted that this includes org.apache.sling.distribution.sample-0.1.2 - I assume this is intentional? Yes, Marius already sent a reply regarding this. Robert Cheers, Stefan On 7/29/15 5:09 PM, Stefan Egli stefane...@apache.org wrote: +1 Cheers, Stefan On 7/29/15 4:25 PM, Marius Petria mpet...@adobe.com wrote: Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/1233301 2 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12323405 Staging repository: https://repository.apache.org/content/repositories/orgapachesling -1304/ 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 1304 /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.
Re: [VOTE] Release Apache Sling Content Distribution Core version 0.1.6
On Wed, 2015-07-29 at 14:25 +, Marius Petria wrote: Please vote to approve this release: +1 Robert
Re: SLING-4556 - Moving org.apache.sling.installer.factory.configuration to the :boot feature
On Tue, 2015-07-28 at 17:22 +0200, Bertrand Delacretaz wrote: Hi, On Tue, Jul 28, 2015 at 5:15 PM, Robert Munteanu romb...@apache.org wrote: ...please take a look at the patch [2] attached to SLING -4556 [3] and let me know if you see any issues with it... That looks good to me, making configurations available early on makes sense. Thanks for looking into this. Committed change at r1693392. Robert
Re: [vote] Accept the contribution of Log Tail Plugin tracked in SLING-4897
On Wed, 2015-07-29 at 13:34 +0530, Varun Nagpal wrote: Hi Robert, Fixed the issues related to AL headers and reattached the zip archive with new md5sum (69576a5b3155684659c1112eb8923274). Looks good to me, thanks! +1 for accepting the contribution Robert Please have a look. Thanks. -- Varun On Fri, Jul 24, 2015 at 7:08 PM, Robert Munteanu romb...@apache.org wrote: On Wed, 2015-07-22 at 19:45 +0530, Varun Nagpal wrote: Hi, This thread is about voting for the acceptance of the Log Tail Plugin tracked in SLING-4897. An archive (sling-logtail.zip, md5sum 6d14f2ef4748c00e63cbbaeda7224e3c) containing the contribution is attached to SLING-4897 and otherwise available at [0]. With a rat check some files fail due to missing/unapproved licenses: Unapproved licenses: src/main/java/org/apache/sling/tail/impl/LogTailerWebConsolePlugin .jav a src/main/java/org/apache/sling/tail/LogFilter.java src/main/resources/libs/tail/css/tail.css src/main/resources/libs/tail/js/tail.js pom.xml To reproduce, change the parent pom version from 22 to 24 and run mvn verify This should be fixed before accepting the contribution. Thanks, Robert
[jira] [Resolved] (SLING-4556) NPE in DiscoveryServiceImpl#activate due to OakSlingRepositoryManager restart during startup
[ https://issues.apache.org/jira/browse/SLING-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-4556. Resolution: Fixed Fixed with https://svn.apache.org/r1693392 NPE in DiscoveryServiceImpl#activate due to OakSlingRepositoryManager restart during startup Key: SLING-4556 URL: https://issues.apache.org/jira/browse/SLING-4556 Project: Sling Issue Type: Bug Components: JCR Reporter: Carsten Ziegeler Assignee: Robert Munteanu Fix For: JCR Oak Server 1.0.0 Attachments: SLING-4556-1.patch 31.03.2015 05:33:44.001 *ERROR* [Thread-77] org.apache.sling.discovery.impl [org.apache.sling.discovery.impl.DiscoveryServiceImpl(85)] The activate method has thrown an exception (java.lang.NullPointerException) java.lang.NullPointerException: null at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1123) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:611) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:599) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:554) at org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:528) at org.apache.sling.discovery.impl.common.resource.ResourceHelper.getOrCreateResource(ResourceHelper.java:45) at org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listAnnouncementsInSameCluster(AnnouncementRegistryImpl.java:150) at org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listInstances(AnnouncementRegistryImpl.java:542) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:443) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.activate(DiscoveryServiceImpl.java:149) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Resolved] (SLING-4917) BasicInitialContentIT fails for the org.apache.sling.jcr.contentloader module
Am 29.07.15 um 23:02 schrieb Oliver Lietz: Radu, the issue is fixed, but I really don't like the use of the startup handler from org.apache.sling.launchpad.karaf in contentloader as this will block a release until I finally release it. We should come up with a generic startup handler _finally_ or use a simple dummy in the tests. What is it used for in the tests? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Updated] (SLING-4834) Jcr trigger should distribute asynchronously
[ https://issues.apache.org/jira/browse/SLING-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4834: --- Assignee: Marius Petria Jcr trigger should distribute asynchronously - Key: SLING-4834 URL: https://issues.apache.org/jira/browse/SLING-4834 Project: Sling Issue Type: Bug Components: Distribution Affects Versions: Content Distribution Core 0.1.2 Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.6 Jcr trigger should distribute asynchronously such that the event listenet does not take too long. That will avoid filling the observation queue under high load. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection API 1.0.4
+1 Cheers, Stefan On 7/29/15 5:55 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329844 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12333112 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1305 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 1305 /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. Thanks, Radu
[jira] [Updated] (SLING-4818) rep:membersList nodes are not distributed correctly
[ https://issues.apache.org/jira/browse/SLING-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4818: --- Assignee: Marius Petria rep:membersList nodes are not distributed correctly --- Key: SLING-4818 URL: https://issues.apache.org/jira/browse/SLING-4818 Project: Sling Issue Type: Bug Components: Distribution Affects Versions: Content Distribution Core 0.1.2 Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.6 In case of groups that have more than 100 members the members are split into a node tree stored under rep:membersList node. Distributing the 101 member of a group causes an error on importing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4808) Empty config values parsed in VaultDistributionPackageBuilderFactory should be treated as null
[ https://issues.apache.org/jira/browse/SLING-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4808: --- Assignee: Marius Petria Empty config values parsed in VaultDistributionPackageBuilderFactory should be treated as null --- Key: SLING-4808 URL: https://issues.apache.org/jira/browse/SLING-4808 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.6 Saving a config of VaultDistributionPackageBuilderFactory from configMgr causes tempJcrFolder= and the associated check session.nodeExists(tempJcrFolder) to fail. The case should be treated exactly as if the property is missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection API 1.0.4
+1 regards antonio On Jul 29, 2015, at 5:55 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329844 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12333112 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1305 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 1305 /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. Thanks, Radu
SlingMainServlet (almost) eats IOException, how to fix?
Hi,
Since SLING-3498 the SlingMainServlet.service method does this:
try {
...do request processing
} catch (IOException ioe) {
log.debug(service: Probably client aborted request or any other
network problem, ioe);
} catch (Throwable T) {
log.error(...
The idea was to avoid polluting the logs with IOException caused by
clients disconnecting prematurely or other network issues.
The problem is that this causes legit IOExceptions throwed by request
processing code to be logged at the debug level only, so effectively
hidden on production systems.
What do people think of changing that catch clause to
} catch (IOException ioe) {
log.error(service: IOException in request processing, ioe);
I think a bit of noise in the logs is better than hiding exceptions
thrown by application code.
Any better ideas?
-Bertrand
[jira] [Commented] (SLING-3498) Don't log stacktrace on IOException
[
https://issues.apache.org/jira/browse/SLING-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647865#comment-14647865
]
Bertrand Delacretaz commented on SLING-3498:
The problem is that this hides legit IOException thrown by application code, as
we don't expect users to run with debug log level active in production. I have
asked for opinions on dl-dev in the SlingMainServlet (almost) eats
IOException, how to fix? thread.
Don't log stacktrace on IOException
---
Key: SLING-3498
URL: https://issues.apache.org/jira/browse/SLING-3498
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.3.2
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: Engine 2.3.4
The SlingMainServlet logs IOExceptions depending on the actual cause:
{code}
} catch (IOException ioe) {
// unwrap any causes (Jetty wraps SocketException in
// EofException)
Throwable cause = ioe;
while (cause.getCause() != null) {
cause = cause.getCause();
}
if (cause instanceof SocketException) {
// if the cause is a SocketException, the client most
// probably
// aborted the request, we do not fill the log with errors
// in this case
log.debug(
service: Socketexception (Client abort or network problem,
ioe);
} else {
// otherwise we want to know why the servlet failed
log.error(
service: Uncaught IO Problem while handling the request,
ioe);
}
} ...
{code}
The idea is to try to find out, whether the IOException is caused by the
client aborting the request or some other problem.
NIO socket channels, though, don't throw SocketException but just IOException
in this case, so this above code will always log an ERROR message with a
stack trace. This message has no real use and we should change this and log
the IOException as an INFO message (if at all) and at most dump the stack
trace as a DEBUG message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4919) Require configuration for webdav related services
[ https://issues.apache.org/jira/browse/SLING-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647844#comment-14647844 ] Carsten Ziegeler commented on SLING-4919: - I'll add them once we release and update launchpad Require configuration for webdav related services - Key: SLING-4919 URL: https://issues.apache.org/jira/browse/SLING-4919 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR Webdav 2.2.2, JCR DavEx 1.2.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Webdav 2.2.4, JCR DavEx 1.2.4 In order to easier enable webdav/davex support, we should make those components require a configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection API 1.0.4
+1 On Thu, Jul 30, 2015 at 6:02 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Updating a release repository during a vote
On Mon, 2015-07-27 at 14:43 +0200, Bertrand Delacretaz wrote: Hi, On Mon, Jul 20, 2015 at 3:25 PM, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote: ... Although versions are cheap for us, it confuses our users when versions are missing. It's even more confusing that AEM 6.1 uses Sling i18n 2.4.0 which was _not_ released. So I'm for reusing here. +1 for reusing versions on cancelled votes... I am strongly against reusing version numbers when artifacts change. As soon as one creates a binary people can copy it around, there's no way to know if that happens or not. Having two versions of an artifact with the same version numbers can cause major confusion. Non-consecutive version numbers are not a problem. Thanks to all for the discussion. I've updated the release management page with the following text: Index: release-management.mdtext === --- release-management.mdtext (revision 1693407) +++ release-management.mdtext (working copy) @@ -159,7 +159,7 @@ Be sure to include all votes in the list and indicate which votes were binding. Consider \-1 votes very carefully. While there is te chnically no veto on release votes, there may be reasons for people to vote \-1. So sometimes it may be better to cancel a release wh en someone, especially a member of the PMC, votes \-1. -If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*. +If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*. Note that any changes to the artifacts under vote require a restart of the process, no matter how trivial. When restarting a vote version numbers must not be reused, since binaries might have already been copied around. If the vote is successful, you need to promote and distribute the release - see *Promoting the Release*. Thanks, Robert
[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647477#comment-14647477 ] Carsten Ziegeler commented on SLING-4895: - [~mpetria] Yes, maybe - however I implemented equals/hashTo for mapping to just compare the key part of the mapping not the value (service user name), as this is usually used to detect duplicate mappings. A duplicate mapping is already there if serviceName/subservicename are the same. That's why I thought to make more drastic changes, but maybe they are not necessary Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling XSS Protection API 1.0.4
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Content Distribution Core version 0.1.6
Am 30.07.15 um 09:17 schrieb Robert Munteanu: On Wed, 2015-07-29 at 14:25 +, Marius Petria wrote: Please vote to approve this release: +1 Robert +1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [jira] [Resolved] (SLING-4917) BasicInitialContentIT fails for the org.apache.sling.jcr.contentloader module
Am 30.07.15 um 09:11 schrieb Oliver Lietz: On Thursday 30 July 2015 08:29:24 Carsten Ziegeler wrote: Am 29.07.15 um 23:02 schrieb Oliver Lietz: Radu, the issue is fixed, but I really don't like the use of the startup handler from org.apache.sling.launchpad.karaf in contentloader as this will block a release until I finally release it. We should come up with a generic startup handler _finally_ or use a simple dummy in the tests. What is it used for in the tests? It's to satisfy Sling Settings (Sling ID is used by content loader). And if there is no startup handler, the JCR isn't setup properly (missing folders). This behavior crept in after Sling 6. Args right, so we should rather fix this instead of dragging in more stuff :) I guess for this problem here, using an older settings version should do the trick Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647433#comment-14647433 ] Marius Petria commented on SLING-4895: -- [~cziegeler] I have to look more closely to your version as it introduces indeed more changes. As for your concerns with conflicting mappings maybe we can just fix that and implement hashCode and equals for mapping to be consistent with compareTo. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4913) Allow exclusion filters on vault package builder
[
https://issues.apache.org/jira/browse/SLING-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647362#comment-14647362
]
Nicolas Peltier commented on SLING-4913:
thx [~mpetria], i confirm you {Code}/home/users|-.*/.tokens{Code} does the
trick for aem users
Allow exclusion filters on vault package builder
Key: SLING-4913
URL: https://issues.apache.org/jira/browse/SLING-4913
Project: Sling
Issue Type: Improvement
Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
Fix For: Content Distribution Core 0.1.6
Allow exclusion filters on vault package builder, for example to exclude all
.tokens nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Updating a release repository during a vote
On Thu, Jul 30, 2015 at 1:05 PM, Robert Munteanu romb...@apache.org wrote: ... I've updated the release management page Thanks! Your changes look good to me. -Bertrand
