[jira] [Resolved] (SLING-4653) [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4653. - Resolution: Fixed I've added a new service property for the picker service, defaulting to false - which was the initial behaviour. Only if it is set to true the parent hierarchie is traversed - this is enabled for the overriding picker [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties - Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Assignee: Carsten Ziegeler Priority: Critical Fix For: Resource Merger 1.2.10 If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4556) NPE in DiscoveryServiceImpl#activate
[ https://issues.apache.org/jira/browse/SLING-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509261#comment-14509261 ] Robert Munteanu commented on SLING-4556: While debugging an unrelated issue I noticed that the OakSlingRepositoryManager is stopped and started three times when starting up Sling, so this can explain this NPE. NPE in DiscoveryServiceImpl#activate Key: SLING-4556 URL: https://issues.apache.org/jira/browse/SLING-4556 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0 Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.4 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)
[jira] [Commented] (SLING-4653) Resource merging properties are ignored if the direct parent of the read resource does not exist
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509173#comment-14509173 ] Carsten Ziegeler commented on SLING-4653: - Traversal of the parent has been introduced with SLING-4311. I'm wondering if it's a use case for the merging resource provider to go up the hierarchie? Resource merging properties are ignored if the direct parent of the read resource does not exist Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4653) [Regression] Merging resource provider is traversing parent hierarchie for finding hide properties
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4653: Summary: [Regression] Merging resource provider is traversing parent hierarchie for finding hide properties (was: [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties) [Regression] Merging resource provider is traversing parent hierarchie for finding hide properties -- Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Assignee: Carsten Ziegeler Priority: Critical Fix For: Resource Merger 1.2.10 If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4653) Resource merging properties are ignored if the direct parent of the read resource does not exist
Joel Richard created SLING-4653: --- Summary: Resource merging properties are ignored if the direct parent of the read resource does not exist Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4653) [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4653: Fix Version/s: Resource Merger 1.2.10 [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties - Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Assignee: Carsten Ziegeler Priority: Critical Fix For: Resource Merger 1.2.10 If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4653) [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4653: --- Assignee: Carsten Ziegeler [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties - Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Assignee: Carsten Ziegeler Priority: Critical Fix For: Resource Merger 1.2.10 If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #19
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Updated] (SLING-4653) [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4653: Summary: [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties (was: Resource merging properties are ignored if the direct parent of the read resource does not exist) [Regression] Merging resource provider is traversing parent hierarchy for finding hide properties - Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Karaf integration tests running times
On Thursday 23 April 2015 14:44:49 Bertrand Delacretaz wrote: On Thu, Apr 23, 2015 at 1:51 PM, Oliver Lietz apa...@oliverlietz.de wrote: ...Apart from that we can create a dedicated build job for Karaf Launchpad That would be great as it looks like that would speed up the contrib build job a lot. Yes, the 53 integration tests currently take 40 minutes when not failing and this is worth a dedicated build job. While we're at it... is there a build job for running Launchpad's integration tests? I still have failing tests when running Launchpad's integration tests against Karaf but I don't think Karaf is the cause (well, there is one test for Felix Http's filter support and Karaf makes use of Pax Web). Regards, O. -Bertrand
Re: Sling IDE Tooling for IntelliJ IDEA
More or less. You find more information about it in https://wiki.eclipse.org/M2E_compatible_maven_plugins#.3Cexecute.2F.3E_mapping. The SCR Mojo is indeed called from Eclipse. Maybe you can call that in IntelliJ directly? Konrad Am 23.04.2015 um 18:50 schrieb Andreas Schaefer Sr. schaef...@me.com: Hi Konrad Thanks for the quick response. So Eclipse is running a “Maven Build” for a class whenever it is compiled? - Andy On Apr 23, 2015, at 1:55 AM, Konrad Windszus konra...@gmx.de wrote: Hi Andy, regarding 1) I am not aware of any existing effort to port this to IntelliJ. Regarding 2) there is the maven-scr-plugin which was made compatible with m2e (the Maven Eclipse Integration) in https://issues.apache.org/jira/browse/FELIX-3358. Basically Eclipse is executing a special maven goal whenever it triggers a compilation which will lead to the modification of the class file (i.e. the bind methods are being added). I am not aware though of a similar mechanism in IntelliJ though. Hope this information helps, Konrad Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com: Hi Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to IntelliJ. So I have a few questions: 1) Did anyone already try that? If so is the code available and for which IntelliJ version? 2) Ran into some problems with the HotSwap of code deployed in Sling. It turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind methods for @Reference which are not there with simple class compilation and hence the HotSwap fails. Now Eclipse is working fine and I am wondering if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that. Cheers - Andy Schaefer
[jira] [Updated] (SLING-4654) Support ResourceResolver.findResources with JCR_MOCK
[
https://issues.apache.org/jira/browse/SLING-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4654:
---
Attachment: SLING-4654-testcasev1.diff
Support ResourceResolver.findResources with JCR_MOCK
Key: SLING-4654
URL: https://issues.apache.org/jira/browse/SLING-4654
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.2.0
Reporter: Konrad Windszus
Attachments: SLING-4654-testcasev1.diff
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResource}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResource}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4654) Support ResourceResolver.findResources with JCR_MOCK
[
https://issues.apache.org/jira/browse/SLING-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4654:
---
Description:
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResources}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResources}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
was:
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResource}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResource}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
Support ResourceResolver.findResources with JCR_MOCK
Key: SLING-4654
URL: https://issues.apache.org/jira/browse/SLING-4654
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.2.0
Reporter: Konrad Windszus
Attachments: SLING-4654-testcasev1.diff
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResources}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResources}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4654) Support ResourceResolver.findResources with JCR_MOCK
[
https://issues.apache.org/jira/browse/SLING-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4654:
---
Attachment: (was: SLING-4654-testcasev1.diff)
Support ResourceResolver.findResources with JCR_MOCK
Key: SLING-4654
URL: https://issues.apache.org/jira/browse/SLING-4654
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.2.0
Reporter: Konrad Windszus
Attachments: SLING-4654-testcasev2.diff
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResources}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResources}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4654) Support ResourceResolver.findResources with JCR_MOCK
[
https://issues.apache.org/jira/browse/SLING-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4654:
---
Attachment: SLING-4654-testcasev2.diff
Support ResourceResolver.findResources with JCR_MOCK
Key: SLING-4654
URL: https://issues.apache.org/jira/browse/SLING-4654
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.2.0
Reporter: Konrad Windszus
Attachments: SLING-4654-testcasev2.diff
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResources}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResources}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Sling IDE Tooling for IntelliJ IDEA
Hi Konrad Thanks for the quick response. So Eclipse is running a “Maven Build” for a class whenever it is compiled? - Andy On Apr 23, 2015, at 1:55 AM, Konrad Windszus konra...@gmx.de wrote: Hi Andy, regarding 1) I am not aware of any existing effort to port this to IntelliJ. Regarding 2) there is the maven-scr-plugin which was made compatible with m2e (the Maven Eclipse Integration) in https://issues.apache.org/jira/browse/FELIX-3358. Basically Eclipse is executing a special maven goal whenever it triggers a compilation which will lead to the modification of the class file (i.e. the bind methods are being added). I am not aware though of a similar mechanism in IntelliJ though. Hope this information helps, Konrad Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com: Hi Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to IntelliJ. So I have a few questions: 1) Did anyone already try that? If so is the code available and for which IntelliJ version? 2) Ran into some problems with the HotSwap of code deployed in Sling. It turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind methods for @Reference which are not there with simple class compilation and hence the HotSwap fails. Now Eclipse is working fine and I am wondering if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that. Cheers - Andy Schaefer
[jira] [Created] (SLING-4654) Support ResourceResolver.findResources with JCR_MOCK
Konrad Windszus created SLING-4654:
--
Summary: Support ResourceResolver.findResources with JCR_MOCK
Key: SLING-4654
URL: https://issues.apache.org/jira/browse/SLING-4654
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.2.0
Reporter: Konrad Windszus
Although JCR Mocks supports mocking queries
(https://sling.apache.org/documentation/development/jcr-mock.html#mocking-queries)
this is not being propagated to the Sling API when using Sling Mocks with
JCR_MOCK as the resource resolver type. Whenever you execute
{{ResourceResolver.findResource}} on such a mock it will always return no
results.
The expected behaviour would be that any mocked queries through
{{MockJcr.setQueryResult}} would be considered also for
{{ResourceResolver.findResource}}. Attached is a test case for Sling Mocks
which currently fails due to findResource not returning anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4653) Resource merging properties are ignored if the direct parent of the read resource does not exist
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4653: Description: If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. was: If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. Resource merging properties are ignored if the direct parent of the read resource does not exist Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4649) FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
[
https://issues.apache.org/jira/browse/SLING-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509364#comment-14509364
]
Oliver Lietz commented on SLING-4649:
-
I do not fully understand your last paragraph, but I hope to make things more
clear with some points:
* framework properties do not break anything in Karaf (Karaf in this case is
just a wrapper/starter for Felix/Equinox like Sling's Launchpad)
* Sling works without setting any special framework properties
* framework properties cannot be added/removed/modified at runtime (AFAIK -
[~cziegeler] knows probably better)
* when installing Sling by features in Karaf the framework (Felix) is already
running
So not using framework properties and component configuration instead is about
user experience. You don't have to shutdown the framework, add/change a
property (e.g. in {{karaf/etc/custom.properties}}) and restart. You can simply
install the required configuration when installing the Sling features in your
running framework. It's a couplet:
{noformat}
karaf@root() feature:repo-add
mvn:org.apache.sling/org.apache.sling.launchpad.karaf-features/0.1.1-SNAPSHOT/xml/features
karaf@root() feature:install sling-launchpad-oak-tar
{noformat}
And just {{sling}} for {{feature:repo-add}} when
{{org.apache.sling.launchpad.karaf-features}} is released.
Shared configuration for {{sling-launchpad-oak-tar}} and
{{sling-launchpad-oak-mongo}} is already in {{sling-launchpad-oak}} (main
launchpad?) where both depend on. I don't see how to simplify further.
You can put configuration into files also, but that doesn't help here?
FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
--
Key: SLING-4649
URL: https://issues.apache.org/jira/browse/SLING-4649
Project: Sling
Issue Type: Bug
Components: Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Labels: sling-IT
Fix For: Launchpad Builder 8
Failed tests:
FullTextIndexingTest.testUploadedPdfIsIndexed:57 RetryLoop failed,
condition is false after 10 seconds: A document containing 'Excepteur' is
found under /FullTextIndexingTest
This last worked on Jenkins with [sling-oak-it-1.7
42|https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.7/42/] -
r1673619, Apr 17, 2015 5:20:55 PM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #20
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-contrib-1.7 #21
See https://builds.apache.org/job/sling-contrib-1.7/changes
[VOTE RESULT] Release Apache Sling Slingstart Maven Plugin
Vote passed with four binding +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Closed] (SLING-4543) i18n: support for json dictionaries
[ https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4543. --- i18n: support for json dictionaries --- Key: SLING-4543 URL: https://issues.apache.org/jira/browse/SLING-4543 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.3.2 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: i18n 2.4.2 Attachments: SLING-4543.patch Support json dictionaries as alternative to individual sling:Message nodes. The fine grained JCR sling:Message node approach does not scale very well when dictionaries contain thousands of entries, at least installation of such a dictionary is slow, but also reading can be affected (even if this is cached), especially viewing in a tree browser becomes impossible. The individual string overlay mechanism (/apps string overlays same /libs string) must still work. In our case (AEM) this can save more than a minute during installation time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4344.
---
Modifying i18n language node in a path outside the resource resolver's search
path will not invalidate the ResourceBundle cache
---
Key: SLING-4344
URL: https://issues.apache.org/jira/browse/SLING-4344
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.3.2
Reporter: Konrad Windszus
Fix For: i18n 2.4.2
Attachments: SLING-4344-v02.patch
Currently any modification of a Sling i18n message will not invalidate the
{{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
basename and contents only outside of the resource resolver's search path are
always empty
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
I would argue that it should be allowed to place language nodes anywhere in
the repository, which seems to work well except for the cache invalidation.
The problem is in the {{loadFully}} method
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
which will only set languageRoots if they are below any of the resource
resolver's search paths.
To reproduce the issue you can just add the following node structure
{code}
/content/languages
+-- English (nt:folder, mix:language)
|+-- jcr:language = en
|+-- basename = myuniquebasename
|+-- m1 (sling:messageEntry)
||+-- sling:key = msg001
||+-- sling:message = This is a message
{code}
Then load the key from this resource bundle (by giving the right basename).
It will internally put the resource bundle into the cache (although all
contents of the given resource bundle are outside any of the default search
paths /apps or /libs). Whenever you change the message that won't be
reflected, because the resource bundle cache is not invalidated (caused by
the empty {{languageRoots}}) therefore the old message would still be
exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4512) Traversal Warnings in OAK while creating i18n JcrResourceBundle
[
https://issues.apache.org/jira/browse/SLING-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4512.
---
Traversal Warnings in OAK while creating i18n JcrResourceBundle
---
Key: SLING-4512
URL: https://issues.apache.org/jira/browse/SLING-4512
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Srijan Bhatnagar
Assignee: Amit Gupta
Fix For: i18n 2.4.2
Attachments: SLING-4512-alex.patch, SLING-4512.diff
org.apache.sling.i18n.impl.JcrResourceBundle#loadFully uses an XPath query to
load [sling:Message] nodes under given paths. If the subtree under the path
is too big (1000), we receive traversal warnings in Oak. The following
warning is generated if the path is /libs/wcm/core/i18n/de :
{code}
GET /content/geometrixx/de.html HTTP/1.1]
org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed 1000
nodes with filter Filter(query=select [jcr:path], [jcr:score], * from
[sling:Message] as a where isdescendantnode(a, '/libs/wcm/core/i18n/de') /*
xpath: /jcr:root/libs/wcm/core/i18n/de//element(*,sling:Message) */,
path=/libs/wcm/core/i18n/de//*); consider creating an index or changing the
query
{code}
A suggestion would be to use
[TreeTraverser|http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/commons/flat/TreeTraverser.html]
instead of XPath query since the subtree is mostly a flat list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4579) Regression introduced by SLING-4512 : JCR API used in i18n implementation
[ https://issues.apache.org/jira/browse/SLING-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4579. --- Regression introduced by SLING-4512 : JCR API used in i18n implementation - Key: SLING-4579 URL: https://issues.apache.org/jira/browse/SLING-4579 Project: Sling Issue Type: Bug Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Critical Fix For: i18n 2.4.2 The i18n module should be free from JCR API usage to allow it to run on any resources providing i18n messages. SLING-4512 unfortunately removed this functionality by directly using JCR API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4580) Remove extra null check for metadata
[
https://issues.apache.org/jira/browse/SLING-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4580.
---
Remove extra null check for metadata
Key: SLING-4580
URL: https://issues.apache.org/jira/browse/SLING-4580
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: i18n 2.4.2
This check in JcrResourceBundle
if (metadata != null) { // test does not implement metadata
should be removed and the test be fixed as metadata at runtime is always not
null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4474) Provide a way to start/stop an instance through maven mojos
[ https://issues.apache.org/jira/browse/SLING-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4474. --- Provide a way to start/stop an instance through maven mojos --- Key: SLING-4474 URL: https://issues.apache.org/jira/browse/SLING-4474 Project: Sling Issue Type: New Feature Components: Maven Plugins and Archetypes Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.1.0 Comparable to the goals from the launchpad plugin, we should provide an easy way to start/stop an instance for running integration tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4620) Slingstart plugin start goal exits even if launchpad.keep.running is set to true
[
https://issues.apache.org/jira/browse/SLING-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4620.
---
Slingstart plugin start goal exits even if launchpad.keep.running is set to
true
Key: SLING-4620
URL: https://issues.apache.org/jira/browse/SLING-4620
Project: Sling
Issue Type: Bug
Components: Maven Plugins and Archetypes
Reporter: Radu Cotescu
Assignee: Carsten Ziegeler
Fix For: Slingstart Maven Plugin 1.1.0
After adapting the Sightly Testing launchpad from SLING-4599 I noticed that
the Maven execution of the Slingstart plugin exits even if the
{{launchpad.keep.running}} property is set to {{true}}:
{noformat}
$ mvn slingstart:start -Dlaunchpad.keep.running=true
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Sling Scripting Sightly Integration Tests
1.0.5-SNAPSHOT
[INFO]
[INFO]
[INFO] --- slingstart-maven-plugin:1.0.5-SNAPSHOT:start (default-cli) @
org.apache.sling.scripting.sightly.testing ---
[INFO] Starting Launchpad jackrabbit-8080...
[INFO] Started Launchpad jackrabbit-8080 [jackrabbit, 8080]
[INFO] Press CTRL-C to stop launchpad instance(s)...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 39.028 s
[INFO] Finished at: 2015-04-14T18:07:42+03:00
[INFO] Final Memory: 11M/160M
[INFO]
{noformat}
I noticed that the {{controlport}} file does not get created under
{{target/jackrabbit-8080/sling/conf}}.
The same issue can be reproduced at {{launchpad/builder}}:
{noformat}
$ mvn slingstart:start -Dlaunchpad.keep.running=true
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Sling Launchpad Application Builder 8-SNAPSHOT
[INFO]
[INFO]
[INFO] --- slingstart-maven-plugin:1.0.5-SNAPSHOT:start (default-cli) @
org.apache.sling.launchpad ---
[INFO] Starting Launchpad _-54984...
[INFO] Started Launchpad _-54984 [null, 54984]
[INFO] Press CTRL-C to stop launchpad instance(s)...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.933 s
[INFO] Finished at: 2015-04-14T18:23:27+03:00
[INFO] Final Memory: 11M/160M
[INFO]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE RESULT] Release Apache Sling i18n 2.4.2
Vote passed with four binding +1 votes and one non binding +1 vote Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling discovery.impl 1.1.2
+1 (non binding) Regards, Timothee 2015-04-23 11:24 GMT+01:00 Stefan Egli stefane...@apache.org: Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329705/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1246 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 1246 /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. Cheers, Stefan
[jira] [Commented] (SLING-4649) FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
[
https://issues.apache.org/jira/browse/SLING-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509000#comment-14509000
]
Robert Munteanu commented on SLING-4649:
I hadn't considered that when I made the change. Looking at the code in
LuceneIndexProviderService I can see that the {{repository.home}} property is a
fallback in case {{localIndexDir}} is not configured
{code:java}
String indexDirPath =
PropertiesUtil.toString(config.get(PROP_LOCAL_INDEX_DIR), null);
if (Strings.isNullOrEmpty(indexDirPath)) {
String repoHome = bundleContext.getProperty(REPOSITORY_HOME);
if (repoHome != null){
indexDirPath = FilenameUtils.concat(repoHome, index);
}
}
{code}
What I don't understand is how the Karaf launchpad interacts with setting
framework properties in the main launchpad. Does anything break in Karaf if we
use framework properties? Can we simplify the Karaf launchpad/features if we
set component properties in the main launchpad?
FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
--
Key: SLING-4649
URL: https://issues.apache.org/jira/browse/SLING-4649
Project: Sling
Issue Type: Bug
Components: Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Labels: sling-IT
Fix For: Launchpad Builder 8
Failed tests:
FullTextIndexingTest.testUploadedPdfIsIndexed:57 RetryLoop failed,
condition is false after 10 seconds: A document containing 'Excepteur' is
found under /FullTextIndexingTest
This last worked on Jenkins with [sling-oak-it-1.7
42|https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.7/42/] -
r1673619, Apr 17, 2015 5:20:55 PM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4639) SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine
[ https://issues.apache.org/jira/browse/SLING-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508666#comment-14508666 ] Michael Kreis commented on SLING-4639: -- Oh sure that's working perfectly. I didn't think about that when I implemented the new processor. SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine --- Key: SLING-4639 URL: https://issues.apache.org/jira/browse/SLING-4639 Project: Sling Issue Type: New Feature Components: Scripting Reporter: Michael Kreis Assignee: Oliver Lietz New Thymeleaf attribute processor which adapts object specified in data-sling-adaptabe to class specified in data-sling-adaptTo and makes object available on the template in the variable specified in data-sling-var. See: https://github.com/apache/sling/pull/83 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-4568.
-
Resolution: Fixed
Thanks for your work and patch, Joel. I've applied the parent hiding handler
part of your patch.
A configuration that defers from the search path is causing for trouble. It
will get out of sync. And we also might want to have a more dynamic search path
in the future (e.g. for per tenant).
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4649) FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
[
https://issues.apache.org/jira/browse/SLING-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508725#comment-14508725
]
Robert Munteanu commented on SLING-4649:
I see that this value for the {{repository.home}} is already 'advertised' at
http://jackrabbit.apache.org/oak/docs/osgi_config.html#Framework_Properties_vs_OSGi_Configuration
FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
--
Key: SLING-4649
URL: https://issues.apache.org/jira/browse/SLING-4649
Project: Sling
Issue Type: Bug
Components: Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Labels: sling-IT
Fix For: Launchpad Builder 8
Failed tests:
FullTextIndexingTest.testUploadedPdfIsIndexed:57 RetryLoop failed,
condition is false after 10 seconds: A document containing 'Excepteur' is
found under /FullTextIndexingTest
This last worked on Jenkins with [sling-oak-it-1.7
42|https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.7/42/] -
r1673619, Apr 17, 2015 5:20:55 PM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3432) pseudo network partition causes job deserialization issue in a cluster (when reading while job is being reassigned)
[ https://issues.apache.org/jira/browse/SLING-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-3432: --- Fix Version/s: (was: Discovery Impl 1.1.2) Discovery Impl 1.1.4 moving from 1.1.2 to 1.1.4 in order to release 1.1.2 now pseudo network partition causes job deserialization issue in a cluster (when reading while job is being reassigned) --- Key: SLING-3432 URL: https://issues.apache.org/jira/browse/SLING-3432 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.1.4 There is a race condition between two instances in a cluster (eg oak or crx): Instance 1 is writing a job with a binary property, instance 2 is reading the job (likely triggered by discovery sending it a topologychangedevent). It looks like instance 2 is reading the job just about while instance 1 is still in the process or completely writing the job, or at least the binary. Resulting in the following exception: 04.03.2014 06:55:39.667 *WARN* [Apache Sling Job Background Loader] org.apache.sling.event.impl.jobs.JobManagerImpl Unable to read job from /var/eventing/jobs/assigned/e4337f8f-47d2-41df-b3ab-0d40b1b2acd4/slingevent:eventadmin/2014/3/3/8/45/cq.wcm.msm.job.pageEvent_9718d7db-85b4-4930-a2ba-11a80d772970_172 java.lang.Exception: Unable to deserialize property 'pageEvent' at org.apache.sling.event.impl.support.ResourceHelper.cloneValueMap(ResourceHelper.java:213) at org.apache.sling.event.impl.jobs.JobManagerImpl.readJob(JobManagerImpl.java:538) at org.apache.sling.event.impl.jobs.BackgroundLoader.loadJobInTheBackground(BackgroundLoader.java:318) at org.apache.sling.event.impl.jobs.BackgroundLoader.loadJobsInTheBackground(BackgroundLoader.java:294) at org.apache.sling.event.impl.jobs.BackgroundLoader.run(BackgroundLoader.java:203) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779) at java.io.ObjectInputStream.init(ObjectInputStream.java:279) at org.apache.sling.event.impl.support.ResourceHelper.cloneValueMap(ResourceHelper.java:208) ... 5 common frames omitted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4568:
Fix Version/s: Resource Merger 1.2.10
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4568:
Priority: Major (was: Critical)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-4568:
---
Assignee: Carsten Ziegeler
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Priority: Critical
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4528) Moving to Oak
[
https://issues.apache.org/jira/browse/SLING-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508700#comment-14508700
]
Robert Munteanu commented on SLING-4528:
[~alessandro] - this should be fixed as of https://svn.apache.org/r1675387 ,
can you please update from svn and try again?
Moving to Oak
-
Key: SLING-4528
URL: https://issues.apache.org/jira/browse/SLING-4528
Project: Sling
Issue Type: Task
Components: JCR
Reporter: Oliver Lietz
Labels: oak
Fix For: JCR Oak Server 1.0.0
_Apache Sling Oak Repository Server_ ({{org.apache.sling.jcr.oak.server}}) is
not released and contains some TODOs and {{JcrRepositoryHacks}}.
What needs to be done for a first release, [~bdelacretaz] and [~mduerig]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4649) FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
[
https://issues.apache.org/jira/browse/SLING-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508698#comment-14508698
]
Robert Munteanu commented on SLING-4649:
[~olli] - I think we should rather be consistent and use the same main repo
location, something like
{noformat}diff --git a/launchpad/builder/src/main/provisioning/oak.txt
b/launchpad/builder/src/main/provisioning/oak.txt
index 757c3d3..c9c9edb 100644
--- a/launchpad/builder/src/main/provisioning/oak.txt
+++ b/launchpad/builder/src/main/provisioning/oak.txt
@@ -74,9 +74,9 @@
[configurations runModes=oak_tar]
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
name=Default\ NodeStore
-repository.home=sling/oak/repository
[configurations runModes=oak_mongo]
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService{noformat}
WDYT?
FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
--
Key: SLING-4649
URL: https://issues.apache.org/jira/browse/SLING-4649
Project: Sling
Issue Type: Bug
Components: Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Labels: sling-IT
Fix For: Launchpad Builder 8
Failed tests:
FullTextIndexingTest.testUploadedPdfIsIndexed:57 RetryLoop failed,
condition is false after 10 seconds: A document containing 'Excepteur' is
found under /FullTextIndexingTest
This last worked on Jenkins with [sling-oak-it-1.7
42|https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.7/42/] -
r1673619, Apr 17, 2015 5:20:55 PM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4639) SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine
[ https://issues.apache.org/jira/browse/SLING-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508679#comment-14508679 ] ASF GitHub Bot commented on SLING-4639: --- Github user m-kay closed the pull request at: https://github.com/apache/sling/pull/83 SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine --- Key: SLING-4639 URL: https://issues.apache.org/jira/browse/SLING-4639 Project: Sling Issue Type: New Feature Components: Scripting Reporter: Michael Kreis Assignee: Oliver Lietz New Thymeleaf attribute processor which adapts object specified in data-sling-adaptabe to class specified in data-sling-adaptTo and makes object available on the template in the variable specified in data-sling-var. See: https://github.com/apache/sling/pull/83 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] sling pull request: SLING-4639 - SlingAdaptToAttrProcessor to supp...
Github user m-kay closed the pull request at: https://github.com/apache/sling/pull/83 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (SLING-4639) SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine
[ https://issues.apache.org/jira/browse/SLING-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kreis resolved SLING-4639. -- Resolution: Not A Problem SlingAdaptToAttrProcessor to support Sling Models in Thymeleaf scripting engine --- Key: SLING-4639 URL: https://issues.apache.org/jira/browse/SLING-4639 Project: Sling Issue Type: New Feature Components: Scripting Reporter: Michael Kreis Assignee: Oliver Lietz New Thymeleaf attribute processor which adapts object specified in data-sling-adaptabe to class specified in data-sling-adaptTo and makes object available on the template in the variable specified in data-sling-var. See: https://github.com/apache/sling/pull/83 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Sling IDE Tooling for IntelliJ IDEA
Hi Andy, regarding 1) I am not aware of any existing effort to port this to IntelliJ. Regarding 2) there is the maven-scr-plugin which was made compatible with m2e (the Maven Eclipse Integration) in https://issues.apache.org/jira/browse/FELIX-3358. Basically Eclipse is executing a special maven goal whenever it triggers a compilation which will lead to the modification of the class file (i.e. the bind methods are being added). I am not aware though of a similar mechanism in IntelliJ though. Hope this information helps, Konrad Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com: Hi Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to IntelliJ. So I have a few questions: 1) Did anyone already try that? If so is the code available and for which IntelliJ version? 2) Ran into some problems with the HotSwap of code deployed in Sling. It turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind methods for @Reference which are not there with simple class compilation and hence the HotSwap fails. Now Eclipse is working fine and I am wondering if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that. Cheers - Andy Schaefer
Re: Sling IDE Tooling for IntelliJ IDEA
Hi Andy, Sounds very good to see intelliJ efforts! I wouldn't know of something in this area so far (lack of resources I suppose). Cheers, Stefan On 4/23/15 10:55 AM, Konrad Windszus konra...@gmx.de wrote: Hi Andy, regarding 1) I am not aware of any existing effort to port this to IntelliJ. Regarding 2) there is the maven-scr-plugin which was made compatible with m2e (the Maven Eclipse Integration) in https://issues.apache.org/jira/browse/FELIX-3358. Basically Eclipse is executing a special maven goal whenever it triggers a compilation which will lead to the modification of the class file (i.e. the bind methods are being added). I am not aware though of a similar mechanism in IntelliJ though. Hope this information helps, Konrad Am 23.04.2015 um 02:47 schrieb Andreas Schaefer Sr. schaef...@me.com: Hi Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to IntelliJ. So I have a few questions: 1) Did anyone already try that? If so is the code available and for which IntelliJ version? 2) Ran into some problems with the HotSwap of code deployed in Sling. It turned out that 'maven-scr-plugin¹ (I think) is generating bind and unbind methods for @Reference which are not there with simple class compilation and hence the HotSwap fails. Now Eclipse is working fine and I am wondering if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that. Cheers - Andy Schaefer
[VOTE] Release Apache Sling discovery.impl 1.1.2
Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329705/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1246 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 1246 /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. Cheers, Stefan
Jenkins build is unstable: sling-contrib-1.7 #16
See https://builds.apache.org/job/sling-contrib-1.7/16/changes
Karaf integration tests running times
Hi, I noticed that our sling-contrib build is quite slow on Jenkins, taking around 90 minutes. Out of those, about 60 minutes are spent in the 'Apache Sling Launchpad Karaf - Integration Tests' module. I am not familiar with that module, but perhaps there's a low-hanging fruit which would allow us to speed up execution and get faster feedback. Robert
Re: Sling IDE Tooling for IntelliJ IDEA
Hi Andy, On Thu, Apr 23, 2015 at 3:47 AM, Andreas Schaefer Sr. schaef...@me.com wrote: Hi Ruben and I are working on a port of the AEM Sling Tooling for Eclipse to IntelliJ. So I have a few questions: That's great news :-) 1) Did anyone already try that? If so is the code available and for which IntelliJ version? 2) Ran into some problems with the HotSwap of code deployed in Sling. It turned out that 'maven-scr-plugin’ (I think) is generating bind and unbind methods for @Reference which are not there with simple class compilation and hence the HotSwap fails. Now Eclipse is working fine and I am wondering if anyone knows what part of Eclipse or the Sling IDE Tooling is doing that. Konrad explained the Eclipse mechanism pretty well. I'll just add that the Sling integration expects an exploded bundle to be present in in the target directory, including: - compiled classes - SCR descriptors ( if applicable ) - compiled class files This is also noted at [1] . Robert [1]: https://sling.apache.org/documentation/development/ide-tooling.html#why-do-i-get-an-errror-about-no-ds-descriptor-found-at
[jira] [Commented] (SLING-4528) Moving to Oak
[
https://issues.apache.org/jira/browse/SLING-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508835#comment-14508835
]
Robert Munteanu commented on SLING-4528:
Made {{repository.home}} usage consistent in https://svn.apache.org/r1675570
Moving to Oak
-
Key: SLING-4528
URL: https://issues.apache.org/jira/browse/SLING-4528
Project: Sling
Issue Type: Task
Components: JCR
Reporter: Oliver Lietz
Labels: oak
Fix For: JCR Oak Server 1.0.0
_Apache Sling Oak Repository Server_ ({{org.apache.sling.jcr.oak.server}}) is
not released and contains some TODOs and {{JcrRepositoryHacks}}.
What needs to be done for a first release, [~bdelacretaz] and [~mduerig]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4652) org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has an empty metatype description
Carsten Ziegeler created SLING-4652: --- Summary: org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has an empty metatype description Key: SLING-4652 URL: https://issues.apache.org/jira/browse/SLING-4652 Project: Sling Issue Type: Improvement Components: Health Check Affects Versions: Health Check Core 1.2.0 Reporter: Carsten Ziegeler Fix For: Health Check Core 1.2.2 The metatype description for org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has just an OCD element without any AD; this is against the spec and with the latest metatype implementation the metatype description is not loaded anymore -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4652) org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has an empty metatype description
[ https://issues.apache.org/jira/browse/SLING-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4652. - Resolution: Fixed Assignee: Carsten Ziegeler Fixed in rev 1675583 org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has an empty metatype description - Key: SLING-4652 URL: https://issues.apache.org/jira/browse/SLING-4652 Project: Sling Issue Type: Improvement Components: Health Check Affects Versions: Health Check Core 1.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Health Check Core 1.2.2 The metatype description for org.apache.sling.hc.core.impl.executor.AsyncHealthCheckExecutor has just an OCD element without any AD; this is against the spec and with the latest metatype implementation the metatype description is not loaded anymore -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.2
+1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Karaf integration tests running times
On Thu, Apr 23, 2015 at 1:51 PM, Oliver Lietz apa...@oliverlietz.de wrote: ...Apart from that we can create a dedicated build job for Karaf Launchpad That would be great as it looks like that would speed up the contrib build job a lot. -Bertrand
[jira] [Reopened] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard reopened SLING-4568:
-
Reopening because the applied patch was incomplete.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #18
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Comment Edited] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509036#comment-14509036
]
Timothee Maret edited comment on SLING-4627 at 4/23/15 1:43 PM:
Thinking about this again. In order to support the cases described in this
issue, what has to be decided is whether or not an instance has left the
cluster the local instance is a member of.
If this holds, then some wait for cluster replication has to be enforced.
It has been pointed that the work of deciding this case would need to be
replicated to all listeners (who depend on cluster replication). However, I
think we may avoid this work, by extending the list of events sent by the
discovery service.
Instead of sending only the TOPOLOGY_CHANGED event, how about extending the
API with a new pair of Event/EventListener ?
Those would be like
{code}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.sling.discovery;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
/**
* An instance event is sent whenever a change in the topology occurs.
*
* This event object might be extended in the future with new event types and
* methods.
*
* @see InstanceEventListener
*/
public class InstanceEvent {
public static enum Type {
/**
* Informs the service about one or more instances added to the
topology.
*/
ADDED,
/**
* Informs the service about one or more instances added to the
topology.
*/
REMOVED,
/**
* One or many properties have been changed on the instance.
*/
PROPERTIES_CHANGED
}
private final Type type;
private final ListInstanceDescription instanceDescriptions;
public InstanceEvent(final Type type, final InstanceDescription...
instanceDescription) {
if (type == null) {
throw new IllegalArgumentException(type must not be null);
}
if (instanceDescription.length == 0) {
throw new IllegalArgumentException(One or more instance
description must be provided);
}
this.type = type;
this.instanceDescriptions = Collections.unmodifiableList(
Arrays.asList(instanceDescription));
}
/**
* Returns the type of this event
*
* @return the type of this event
*/
public Type getType() {
return type;
}
/**
* Returns the view which was valid up until now.
* p
* This is null in case of codeTOPOLOGY_INIT/code
*
* @return the view which was valid up until now, or null in case of a fresh
* instance start
*/
public ListInstanceDescription getInstances() {
return instanceDescriptions;
}
@Override
public String toString() {
return InstanceEvent{ +
type= + type +
, instanceDescriptions= + instanceDescriptions +
'}';
}
}
{code}
Using dedicated handler would allow to only dispatch the events to the pieces
of the code that may require it (such as the Sling JobManager) in order to take
action.
Since the InstanceDescription allows to access the cluster view (through API)
the service could determine whether or not it is in the same cluster view.
Alternatively, a a new event focused on the view changes
{code}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for
Re: Karaf integration tests running times
While we're at it, my build takes forever at Building Apache Sling Launchpad Debian Package Builder 8-SNAPSHOT it seems its executing scripts and whatnot. Does anyone know what it actually does? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509036#comment-14509036
]
Timothee Maret commented on SLING-4627:
---
Thinking about this again. In order to support the cases described in this
issue, what has to be decided is whether or not an instance has left the
cluster the local instance is a member of.
If this holds, then some wait for cluster replication has to be enforced.
It has been pointed that the work of deciding this case would need to be
replicated to all listeners (who depend on cluster replication). However, I
think we may avoid this work, by extending the list of events sent by the
discovery service.
Instead of sending only the TOPOLOGY_CHANGED event, how about extending the
API with a new pair of Event/EventListener ?
Those would be like
{code}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.sling.discovery;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
/**
* An instance event is sent whenever a change in the topology occurs.
*
* This event object might be extended in the future with new event types and
* methods.
*
* @see InstanceEventListener
*/
public class InstanceEvent {
public static enum Type {
/**
* Informs the service about one or more instances added to the
topology.
*/
ADDED,
/**
* Informs the service about one or more instances added to the
topology.
*/
REMOVED,
/**
* One or many properties have been changed on the instance.
*/
PROPERTIES_CHANGED
}
private final Type type;
private final ListInstanceDescription instanceDescriptions;
public InstanceEvent(final Type type, final InstanceDescription...
instanceDescription) {
if (type == null) {
throw new IllegalArgumentException(type must not be null);
}
if (instanceDescription.length == 0) {
throw new IllegalArgumentException(One or more instance
description must be provided);
}
this.type = type;
this.instanceDescriptions = Collections.unmodifiableList(
Arrays.asList(instanceDescription));
}
/**
* Returns the type of this event
*
* @return the type of this event
*/
public Type getType() {
return type;
}
/**
* Returns the view which was valid up until now.
* p
* This is null in case of codeTOPOLOGY_INIT/code
*
* @return the view which was valid up until now, or null in case of a fresh
* instance start
*/
public ListInstanceDescription getInstances() {
return instanceDescriptions;
}
@Override
public String toString() {
return InstanceEvent{ +
type= + type +
, instanceDescriptions= + instanceDescriptions +
'}';
}
}
{code}
Using dedicated handler would allow to only dispatch the events to the pieces
of the code that may require it (such as the Sling JobManager) in order to take
action.
TOPOLOGY_CHANGED in an eventually consistent repository
---
Key: SLING-4627
URL: https://issues.apache.org/jira/browse/SLING-4627
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Egli
Priority: Critical
This is a parent ticket describing the +coordination effort needed between
properly sending TOPOLOGY_CHANGED when running ontop of an eventually
consistent repository+. These findings are independent of the implementation
details used inside the discovery implementation, so apply to discovery.impl,
discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific
implementation are best created separately (eg sub-task or related..). Also
note that this assumes immediately sending TOPOLOGY_CHANGING as described [in
[jira] [Comment Edited] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509036#comment-14509036
]
Timothee Maret edited comment on SLING-4627 at 4/23/15 1:34 PM:
Thinking about this again. In order to support the cases described in this
issue, what has to be decided is whether or not an instance has left the
cluster the local instance is a member of.
If this holds, then some wait for cluster replication has to be enforced.
It has been pointed that the work of deciding this case would need to be
replicated to all listeners (who depend on cluster replication). However, I
think we may avoid this work, by extending the list of events sent by the
discovery service.
Instead of sending only the TOPOLOGY_CHANGED event, how about extending the
API with a new pair of Event/EventListener ?
Those would be like
{code}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.sling.discovery;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
/**
* An instance event is sent whenever a change in the topology occurs.
*
* This event object might be extended in the future with new event types and
* methods.
*
* @see InstanceEventListener
*/
public class InstanceEvent {
public static enum Type {
/**
* Informs the service about one or more instances added to the
topology.
*/
ADDED,
/**
* Informs the service about one or more instances added to the
topology.
*/
REMOVED,
/**
* One or many properties have been changed on the instance.
*/
PROPERTIES_CHANGED
}
private final Type type;
private final ListInstanceDescription instanceDescriptions;
public InstanceEvent(final Type type, final InstanceDescription...
instanceDescription) {
if (type == null) {
throw new IllegalArgumentException(type must not be null);
}
if (instanceDescription.length == 0) {
throw new IllegalArgumentException(One or more instance
description must be provided);
}
this.type = type;
this.instanceDescriptions = Collections.unmodifiableList(
Arrays.asList(instanceDescription));
}
/**
* Returns the type of this event
*
* @return the type of this event
*/
public Type getType() {
return type;
}
/**
* Returns the view which was valid up until now.
* p
* This is null in case of codeTOPOLOGY_INIT/code
*
* @return the view which was valid up until now, or null in case of a fresh
* instance start
*/
public ListInstanceDescription getInstances() {
return instanceDescriptions;
}
@Override
public String toString() {
return InstanceEvent{ +
type= + type +
, instanceDescriptions= + instanceDescriptions +
'}';
}
}
{code}
Using dedicated handler would allow to only dispatch the events to the pieces
of the code that may require it (such as the Sling JobManager) in order to take
action.
Since the InstanceDescription allows to access the cluster view (through API)
the service could determine whether or not it is in the same cluster view.
was (Author: marett):
Thinking about this again. In order to support the cases described in this
issue, what has to be decided is whether or not an instance has left the
cluster the local instance is a member of.
If this holds, then some wait for cluster replication has to be enforced.
It has been pointed that the work of deciding this case would need to be
replicated to all listeners (who depend on cluster replication). However, I
think we may avoid this work, by extending the list of events sent by the
discovery service.
Instead of sending only the TOPOLOGY_CHANGED event, how about extending the
API with a new pair of Event/EventListener ?
Those would be like
{code}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor
[jira] [Commented] (SLING-4649) FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
[
https://issues.apache.org/jira/browse/SLING-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508857#comment-14508857
]
Oliver Lietz commented on SLING-4649:
-
We cannot be consistent across deployments (at least not in a comfortable
manner) with {{repository.home}} under {{\[settings\]}}/{{sling.properties}} as
it is a framework property which cannot be set in a Karaf Feature. So I'm in
favor for configuration per service as done in
[r1675575|https://svn.apache.org/r1675575] or Karaf.
FullTextIndexingTest.testUploadedPdfIsIndexed fails on Oak
--
Key: SLING-4649
URL: https://issues.apache.org/jira/browse/SLING-4649
Project: Sling
Issue Type: Bug
Components: Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Labels: sling-IT
Fix For: Launchpad Builder 8
Failed tests:
FullTextIndexingTest.testUploadedPdfIsIndexed:57 RetryLoop failed,
condition is false after 10 seconds: A document containing 'Excepteur' is
found under /FullTextIndexingTest
This last worked on Jenkins with [sling-oak-it-1.7
42|https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.7/42/] -
r1673619, Apr 17, 2015 5:20:55 PM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.2
+1 Cheers, Stefan On 4/23/15 12:24 PM, Stefan Egli stefane...@apache.org wrote: Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329705/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1246 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 1246 /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. Cheers, Stefan
Jenkins build is still unstable: sling-contrib-1.7 #17
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Updated] (SLING-4647) Max pull items for http transport handler should only be applied to PULL requests
[ https://issues.apache.org/jira/browse/SLING-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-4647: - Fix Version/s: Content Distribution Core 0.1.2 Max pull items for http transport handler should only be applied to PULL requests - Key: SLING-4647 URL: https://issues.apache.org/jira/browse/SLING-4647 Project: Sling Issue Type: Bug Components: Distribution Affects Versions: Content Distribution Core 0.1.1 Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.2 Only pull requests can produce different results and hence the other types (TEST, ADD, DELETE) should only be iterated once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4647) Max pull items for http transport handler should only be applied to PULL requests
[ https://issues.apache.org/jira/browse/SLING-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508939#comment-14508939 ] Marius Petria commented on SLING-4647: -- Committed revision 1675577. Max pull items for http transport handler should only be applied to PULL requests - Key: SLING-4647 URL: https://issues.apache.org/jira/browse/SLING-4647 Project: Sling Issue Type: Bug Components: Distribution Affects Versions: Content Distribution Core 0.1.1 Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.2 Only pull requests can produce different results and hence the other types (TEST, ADD, DELETE) should only be iterated once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4651) Ensure that pulled packages are only deleted when they reach the coordinator queue
Marius Petria created SLING-4651: Summary: Ensure that pulled packages are only deleted when they reach the coordinator queue Key: SLING-4651 URL: https://issues.apache.org/jira/browse/SLING-4651 Project: Sling Issue Type: Bug Components: Distribution Affects Versions: Content Distribution Core 0.1.1 Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution Core 0.1.2 Packages pulled from a remote endpoint are deleted when they reach the coordinating instance, but they should be deleted when they are actually added to the processing queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4411) provide Oak features
[
https://issues.apache.org/jira/browse/SLING-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lietz updated SLING-4411:
Description:
provide features for Oak as we have now for Jackrabbit:
* {{oak-sling}}
* {{sling-jcr-oak}}
* {{sling-launchpad-oak}}
* {{sling-launchpad-oak-tar}}
* {{sling-launchpad-oak-mongo}}
was:
provide features for Oak as we have now for Jackrabbit:
* {{oak-sling}}
* {{sling-jcr-oak}}
* {{sling-launchpad-oak}}
provide Oak features
Key: SLING-4411
URL: https://issues.apache.org/jira/browse/SLING-4411
Project: Sling
Issue Type: New Feature
Components: Launchpad
Reporter: Oliver Lietz
Assignee: Oliver Lietz
Fix For: Launchpad Karaf Features 0.2.0
provide features for Oak as we have now for Jackrabbit:
* {{oak-sling}}
* {{sling-jcr-oak}}
* {{sling-launchpad-oak}}
* {{sling-launchpad-oak-tar}}
* {{sling-launchpad-oak-mongo}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Karaf integration tests running times
On Thursday 23 April 2015 13:46:52 Robert Munteanu wrote: Hi, Hi Robert, I noticed that our sling-contrib build is quite slow on Jenkins, taking around 90 minutes. Out of those, about 60 minutes are spent in the 'Apache Sling Launchpad Karaf - Integration Tests' module. it takes 20 - 30 minutes on my MBP (2,6 GHz/16 GB), so 60 minutes on a slower machine sounds reasonable. I am not familiar with that module, but perhaps there's a low-hanging fruit which would allow us to speed up execution and get faster feedback. I don't think so. Every test starts a fresh instance to eliminate side effects. We may check if running tests in parallel is possible and speeds things up. Apart from that we can create a dedicated build job for Karaf Launchpad. Regards, O. Robert
