[VOTE RESULT] Release Apache Sling Parent 29

2016-10-16 Thread Carsten Ziegeler 
The vote passed with five binding +1 votes

 Thanks

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: What all changes does ResourceChangeListener are interested in

2016-10-16 Thread Carsten Ziegeler 
Chetan Mehrotra wrote
> Oak would be collecting the name of the properties (OAK-4907) which
> got changed in a given commit and that can be used for filtering. This
> I think should help the MapEntries case and probably the resourceType
> case also. They can just hint for those property names and then
> listener would only be called if there is some change in those
> properties
> 
>> I would rather go with a "property names filter hint" - and if we detect
> other use cases we add another property for that.
> 
> Makes sense. This would keep things simple and precise

I plan to release API early this week :) So it would be great if we
could get this in, or we move it to the next api release.

> 
>> Yes, and as mentioned a check based on a resource type is not that easy,
> 
> Can you provide some details on what kind of change the impl is
> interested in. Is it change in the value of resourceType property? Any
> pseudo code of the kind of logic that listener would be performing.
> That would help in determining if we can make this case faster
> 

The code is usually interested in the change of a resource of a specific
type,
for example, if a page is added, removed or changed. This does not mean
that the sling:resourceType property changed, but something else on that
node. In addition that node could have a resourceType property set to
myapp:MyPage which inherits through five levels from sling:Page (let's
assume it would exist) and the listener would be registered for being
interested in sling:Page.
The logic to calculate the resource type hierarchy is quiet complex and
requires access to a resource resolver to do so as potentially several
resources in the resource tree must be traversed to get the result.

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-6163) Improve observation of files in JCR

2016-10-16 Thread Chetan Mehrotra (JIRA) 

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

Chetan Mehrotra commented on SLING-6163:


With OAK-4907 we are collecting nodeType of ancestor nodes also which I thing 
should help here. So this can also be type of hint

/cc [~egli] 

> Improve observation of files in JCR
> ---
>
> Key: SLING-6163
> URL: https://issues.apache.org/jira/browse/SLING-6163
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> Currently, if a jcr:content node is modified, and an observation event is 
> sent out, the jcr listener reads the parent node to find out if this 
> jcr:content is a sub node of a file. If so, it reports a change on the file 
> node.
> This is required for all listeners interested in changes in files, as they 
> usually listen for a file node change, but not for the sub node /jcr:content 
> - which doesn't exist with other resource providers anyway
> The problem is that this read is done for every change of a jcr:content node, 
> regardless whether this is a file. And if several props change on such a 
> node, it is read over and over again



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: What all changes does ResourceChangeListener are interested in

2016-10-16 Thread Chetan Mehrotra 
Oak would be collecting the name of the properties (OAK-4907) which
got changed in a given commit and that can be used for filtering. This
I think should help the MapEntries case and probably the resourceType
case also. They can just hint for those property names and then
listener would only be called if there is some change in those
properties

> I would rather go with a "property names filter hint" - and if we detect
other use cases we add another property for that.

Makes sense. This would keep things simple and precise

> Yes, and as mentioned a check based on a resource type is not that easy,

Can you provide some details on what kind of change the impl is
interested in. Is it change in the value of resourceType property? Any
pseudo code of the kind of logic that listener would be performing.
That would help in determining if we can make this case faster

Chetan Mehrotra


On Sat, Oct 15, 2016 at 7:51 PM, Carsten Ziegeler  wrote:
> Dominik Süß wrote
>> For me one of the most interesting filters for "native" filtering would be
>> based on ResourceType (& RT changes). Optimally we would even have the
>> option to filter by ResourceType and its SubTypes - but detecting the
>> subtypes is something that would go beyond a hint (basically preprocessing
>> a hint to "unfold" it into all of the subtypes to watch out for).
>>
>> I guess within the ResourceTypes the best practice would go into the
>> direction of SubTyping whenever the group covered is too generic and needs
>> to be treated differently.
>>
> Yes, and as mentioned a check based on a resource type is not that easy,
> you need to check the resource type property, the super type property,
> maybe the jcr primary node type and then also walk up the resource type
> hierarchy.
> If Oak would provide a hook for registering these additional checks then
> we "maybe" could do it.
>
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Commented] (SLING-6163) Improve observation of files in JCR

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-6163:
-

I think we have three options:
- we leave it as is 
- For files we find a way that Oak can already send us a changed event for the 
parent file node of jcr:content
- instead of reading, we simply always send two events: changed for the 
jcr:content node and for it's parent, regardless whether this is a file
Maybe there are more/better options?

> Improve observation of files in JCR
> ---
>
> Key: SLING-6163
> URL: https://issues.apache.org/jira/browse/SLING-6163
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> Currently, if a jcr:content node is modified, and an observation event is 
> sent out, the jcr listener reads the parent node to find out if this 
> jcr:content is a sub node of a file. If so, it reports a change on the file 
> node.
> This is required for all listeners interested in changes in files, as they 
> usually listen for a file node change, but not for the sub node /jcr:content 
> - which doesn't exist with other resource providers anyway
> The problem is that this read is done for every change of a jcr:content node, 
> regardless whether this is a file. And if several props change on such a 
> node, it is read over and over again



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6163) Improve observation of files in JCR

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated SLING-6163:

Description: 
Currently, if a jcr:content node is modified, and an observation event is sent 
out, the jcr listener reads the parent node to find out if this jcr:content is 
a sub node of a file. If so, it reports a change on the file node.
This is required for all listeners interested in changes in files, as they 
usually listen for a file node change, but not for the sub node /jcr:content - 
which doesn't exist with other resource providers anyway

The problem is that this read is done for every change of a jcr:content node, 
regardless whether this is a file. And if several props change on such a node, 
it is read over and over again

  was:
Currently, if a jcr:content node is modified, and an observation event is sent 
out, the jcr listener reads the parent node to find out if this jcr:content is 
a sub node of a file. If so, it reports a change on the file node.
This is required for all listeners interested in changes in files, as they 
usually listen for a file node change, but not for the sub node /jcr:content - 
which doesn't exist with other resource providers anyway


> Improve observation of files in JCR
> ---
>
> Key: SLING-6163
> URL: https://issues.apache.org/jira/browse/SLING-6163
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> Currently, if a jcr:content node is modified, and an observation event is 
> sent out, the jcr listener reads the parent node to find out if this 
> jcr:content is a sub node of a file. If so, it reports a change on the file 
> node.
> This is required for all listeners interested in changes in files, as they 
> usually listen for a file node change, but not for the sub node /jcr:content 
> - which doesn't exist with other resource providers anyway
> The problem is that this read is done for every change of a jcr:content node, 
> regardless whether this is a file. And if several props change on such a 
> node, it is read over and over again



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6163) Improve observation of files in JCR

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-6163:
-

As a first improvement, we only read the parent node on change events - for 
node added and removed we don't need to do this, as the jcr:content node is 
mandatory, so if it is added the above file node is added as well, same for 
remove

> Improve observation of files in JCR
> ---
>
> Key: SLING-6163
> URL: https://issues.apache.org/jira/browse/SLING-6163
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> Currently, if a jcr:content node is modified, and an observation event is 
> sent out, the jcr listener reads the parent node to find out if this 
> jcr:content is a sub node of a file. If so, it reports a change on the file 
> node.
> This is required for all listeners interested in changes in files, as they 
> usually listen for a file node change, but not for the sub node /jcr:content 
> - which doesn't exist with other resource providers anyway



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6163) Improve observation of files in JCR

2016-10-16 Thread Carsten Ziegeler (JIRA) 
Carsten Ziegeler created SLING-6163:
---

 Summary: Improve observation of files in JCR
 Key: SLING-6163
 URL: https://issues.apache.org/jira/browse/SLING-6163
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.9.0


Currently, if a jcr:content node is modified, and an observation event is sent 
out, the jcr listener reads the parent node to find out if this jcr:content is 
a sub node of a file. If so, it reports a change on the file node.
This is required for all listeners interested in changes in files, as they 
usually listen for a file node change, but not for the sub node /jcr:content - 
which doesn't exist with other resource providers anyway



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5235) Remove loginAdministrative() usage from org.apache.sling.resourceresolver

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler edited comment on SLING-5235 at 10/16/16 1:26 PM:
---

5 occurences:

ResourceResolverWebConsolePlugin - this is getting an admin resource resolver 
to test the mapping - requires read over the whole repo

ResourceResolverControl - admin resource resolver is used to read the type 
hierarchy - requires read over the search paths

MapEntries - admin RR for alias and vanity path (2 occurences) - requires read 
over the configured paths (several paths for alias config, vanity config, by 
default /)

OsgiObservationBridge - admin RR to read resource type etc for sending out 
observation events, requires read on /


was (Author: cziegeler):
5 occurences:

ResourceResolverWebConsolePlugin - this is getting an admin resource resolver 
to test the mapping

ResourceResolverControl - admin resource resolver is used to read the type 
hierarchy

MapEntries - admin RR for alias and vanity path (2 occurences)

OsgiObservationBridge - admin RR to read resource type etc for sending out 
observation events

> Remove loginAdministrative() usage from org.apache.sling.resourceresolver
> -
>
> Key: SLING-5235
> URL: https://issues.apache.org/jira/browse/SLING-5235
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Antonio Sanso
> Fix For: Resource Resolver 1.5.0
>
>
> counted 6 occurrences



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5235) Remove loginAdministrative() usage from org.apache.sling.resourceresolver

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-5235:
-

5 occurences:

ResourceResolverWebConsolePlugin - this is getting an admin resource resolver 
to test the mapping

ResourceResolverControl - admin resource resolver is used to read the type 
hierarchy

MapEntries - admin RR for alias and vanity path (2 occurences)

OsgiObservationBridge - admin RR to read resource type etc for sending out 
observation events

> Remove loginAdministrative() usage from org.apache.sling.resourceresolver
> -
>
> Key: SLING-5235
> URL: https://issues.apache.org/jira/browse/SLING-5235
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Antonio Sanso
> Fix For: Resource Resolver 1.5.0
>
>
> counted 6 occurrences



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6004) JspScriptEngineFactory should move to new ResourceChangeListener API

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated SLING-6004:

Fix Version/s: Scripting JSP 2.1.10

> JspScriptEngineFactory should move to new ResourceChangeListener API  
> -
>
> Key: SLING-6004
> URL: https://issues.apache.org/jira/browse/SLING-6004
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Fix For: Scripting JSP 2.1.10
>
> Attachments: patch.txt
>
>
> org.apache.sling.scripting.jsp.JspScriptEngineFactory currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6004) JspScriptEngineFactory should move to new ResourceChangeListener API

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reassigned SLING-6004:
---

Assignee: Carsten Ziegeler

> JspScriptEngineFactory should move to new ResourceChangeListener API  
> -
>
> Key: SLING-6004
> URL: https://issues.apache.org/jira/browse/SLING-6004
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
> Attachments: patch.txt
>
>
> org.apache.sling.scripting.jsp.JspScriptEngineFactory currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-4867.
-
Resolution: Fixed

I think the problem is rather a bug in the installer integration test: it does 
not wait until all bundles from the ManyBundlesTest are installed, launches the 
next test and that gets a wrong initial state.
Fixed the test case in rev 1765152
I've also improved the state handling in the installer a little bit


> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reopened SLING-4867:
-

Not sure if it is related to the above change, but integration tests fail no 
with:
noActiveResources(org.apache.sling.launchpad.webapp.integrationtest.installer.ServerSideInstallerTest)
  Time elapsed: 0.653 sec  <<< FAILURE!
java.lang.AssertionError: Active resources found: 
[group[[resource[entityId=bundle:org.apache.sling.testbundle.InstallManyBundlesTest.4a84e6dd-3129-46eb-be31-bad8f77177d4_upgradetest,
 scheme=jcrinstall, 
url=jcrinstall:/apps/InstallManyBundlesTest/4a84e6dd-3129-46eb-be31-bad8f77177d4/install/org.apache.sling.testbundle.InstallManyBundlesTest.4a84e6dd-3129-46eb-be31-bad8f77177d4_upgradetest.9.jar,
 type=bundle, state=UNINSTALLED, version=42.0.9, lastChange=1476548965424, 
priority=200, digest=1476548964497
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.sling.launchpad.webapp.integrationtest.installer.ServerSideInstallerTest.noActiveResources(ServerSideInstallerTest.java:61)

which shows an active resource in the uninstall state

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Parent 29

2016-10-16 Thread Oliver Lietz 
On Friday 14 October 2016 07:57:39 Carsten Ziegeler wrote:
> Hi,
> 
> We solved 4 issues for this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338102

+1

O.

[jira] [Commented] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-6070:
-

I've optimized the memory handling a little bit, reduced unnecessary object 
creation, but still the whole set is built before it is send out.
The properties support is deprecated and removed from the listener.
I think that's all we can do for now
[~egli] WDYT?

> Reduce temporary storage required in JcrResourceListener, call reportChanges 
> earlier
> 
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Stefan Egli
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> As noticed in OAK-4581 
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
>  one advantage of using OakResourceListener over JcrResourceListener (hence 
> the term 'optimize for oak' of the config parameter) is that 
> OakResourceListener uses a NodeObserver, which calls added/removed/changed 
> after each child traversal has finished. This will in turn be used by the 
> OakResourceListener to call ObservationReporter.reportChanges. In the 
> JcrResourceListener.onEvent case however this is not possible, as the events 
> are delivered for each node/property individually, and they first have to be 
> 'mapped' to ResourceChanges. This is currently done by keeping maps of 
> added/removed/changed ResourceChanges and only after all events (that are 
> passed in 1 onEvent) are processed is reportChanges invoked. This has the 
> downside of a potentially very large temporary memory usage (these maps can 
> get big).
> A suggested improvement is to follow the same pattern as is done in the 
> OakResourceListener/NodeObserver pair: to forward the events (by callling 
> reportChanges) as early as possible. Since Oak uses a breadth-first tree 
> traversal when compiling the jcr events, this fact can be used to detect the 
> earliest possible moment to forward events, which is as soon as a child 
> traversal has finished. That way, only parent changes need to be kept, not 
> the entire tree of changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-4867.
-
Resolution: Fixed

Can't reproduce the problem any with the additional lock

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-4867:
-

Added an additional lock in rev 1765129

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-4867:
-

Reopening as I'm seeing this now happening a lot in the launchpad integration 
tests.
The problem is that even getXXX methods change the state by sorting the array - 
this sorting is needed to avoid other problems with the sort order (we had them 
before)

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reopened SLING-4867:
-
  Assignee: Carsten Ziegeler

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4867) EntityResourceList should be thread-safe

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated SLING-4867:

Fix Version/s: Installer Core 3.6.10

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5751) Remove old unused code for installing bundles

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5751.
---

> Remove old unused code for installing bundles
> -
>
> Key: SLING-5751
> URL: https://issues.apache.org/jira/browse/SLING-5751
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12
>
>
> It seems the Sling class has some very old code about autostart bundles. I 
> think we could remove it as it does not seem to be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5587) Improve ControlListener#generateKey

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5587.
---

> Improve ControlListener#generateKey
> ---
>
> Key: SLING-5587
> URL: https://issues.apache.org/jira/browse/SLING-5587
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
> Fix For: Launchpad Base 2.6.12
>
>
> The ControlListener#generateKey method can be improved in order to use more 
> standard and safe method to generate a secretkey



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6127) Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 3.0.16

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-6127.
---

> Update to Apache Felix Http Jetty 3.4.0 and Http Bridge 3.0.16
> --
>
> Key: SLING-6127
> URL: https://issues.apache.org/jira/browse/SLING-6127
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>
> We should update the versions to get the latest features / bug fixes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5626) Start level for bundles in the boot section is not correctly set on update

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5626.
---

> Start level for bundles in the boot section is not correctly set on update
> --
>
> Key: SLING-5626
> URL: https://issues.apache.org/jira/browse/SLING-5626
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.6.10
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12
>
>
> When a bundle is updated which is in the new version in the boot section but 
> was in the old version at a different start level, the start level is not 
> changed.
> Therefore although the intention is to start this bundle as a first bundle, 
> it's not happening



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5963) Update Felix Bundles

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5963.
---

> Update Felix Bundles
> 
>
> Key: SLING-5963
> URL: https://issues.apache.org/jira/browse/SLING-5963
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>
> We should update launchpad builder with:
> [INFO]   org.apache.felix:org.apache.felix.configadmin  1.8.8 -> 
> 1.8.10
> [INFO]   org.apache.felix:org.apache.felix.http.jetty .. 3.2.2 -> 
> 3.2.4
> [INFO]   org.apache.felix:org.apache.felix.http.sslfilter .. 1.0.4 -> 
> 1.1.0
> [INFO]   org.apache.felix:org.apache.felix.scr . 2.0.2 -> 
> 2.0.6
> [INFO]   org.apache.felix:org.apache.felix.webconsole  4.2.14 -> 
> 4.2.16
> and launchpad base with
> org.apache.felix.http.bridge 3.0.12



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5951) Lauchpad should fail fast with Java < 8

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5951.
---

> Lauchpad should fail fast with Java < 8
> ---
>
> Key: SLING-5951
> URL: https://issues.apache.org/jira/browse/SLING-5951
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>
> As org.apache.felix.http.jetty now requires Java 8, the launchpad should fail 
> quickly if started with a version that's lower than that.
> As suggested by Carsten, compiling launchpad.base with Java 8 does implement 
> that requirement. It won't work for other launchers but that's a good first 
> step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5883) Use Apache Felix Http Bridge 3.0.10 and Http Jetty 3.2.2

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5883.
---

> Use Apache Felix Http Bridge 3.0.10 and Http Jetty 3.2.2
> 
>
> Key: SLING-5883
> URL: https://issues.apache.org/jira/browse/SLING-5883
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>
> We should use the latest versions in order to get all bug fixes and 
> improvements
> Note: Jetty requires Java 8 (has been discussed on the mailing list, and 
> consensus was that this is OK)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5642) Remove use of deprecated methods and update code to R6

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5642.
---

> Remove use of deprecated methods and update code to R6
> --
>
> Key: SLING-5642
> URL: https://issues.apache.org/jira/browse/SLING-5642
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12
>
>
> We should update our code to use R6 features and avoid using deprecated stuff 
> like PackageAdmin etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5641) Detection of system bundle fragment is incomplete

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-5641.
---

> Detection of system bundle fragment is incomplete
> -
>
> Key: SLING-5641
> URL: https://issues.apache.org/jira/browse/SLING-5641
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.6.10
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12
>
>
> The current check when executing the uninstall directive to detect whether a 
> fragment to the system bundle is deleted is wrong. It just checks for the 
> directive "framework". However this directive is the default.
> Therefore it should rather check for the symbolic name alias "system.bundle"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6097) Update to Felix Framework 5.6.0

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler closed SLING-6097.
---

> Update to Felix Framework 5.6.0
> ---
>
> Key: SLING-6097
> URL: https://issues.apache.org/jira/browse/SLING-6097
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.6.12, Launchpad Builder 9
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6162) Deprecate PathMapper

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-6162.
-
Resolution: Fixed

Deprecated the service and added a warning to the logs

> Deprecate PathMapper
> 
>
> Key: SLING-6162
> URL: https://issues.apache.org/jira/browse/SLING-6162
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> The path mapper has been added to our code base as an idea to do a path based 
> mapping of JCR resources within Sling, e.g. to support different versions of 
> libs and apps.
> This idea never took off, so I think we should deprecated this. Especially 
> with Oak supporting multiplexed repositories this becomes obsolete



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6161) Should Path.matches support glob pattern as parameter?

2016-10-16 Thread Carsten Ziegeler (JIRA) 
Carsten Ziegeler created SLING-6161:
---

 Summary: Should Path.matches support glob pattern as parameter?
 Key: SLING-6161
 URL: https://issues.apache.org/jira/browse/SLING-6161
 Project: Sling
  Issue Type: Task
  Components: API
Affects Versions: API 2.14.2
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: API 2.15.0


With SLING-5909 a new behaviour has been introduced to Path.matches() which 
supports matches a Path against a glob pattern.
The attached test only convers a Path object with "/", but it is unclear what 
the intend of this change actually is - and what the semantics is.
The javadoc of matches() right now clearly states that the argument should be a 
path, therefore glob pattern is not supported in that method.
[~radu.cotescu] Could you please comment on the intended behaviour?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6161) Should Path.matches support glob pattern as parameter?

2016-10-16 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated SLING-6161:

Priority: Blocker  (was: Major)

> Should Path.matches support glob pattern as parameter?
> --
>
> Key: SLING-6161
> URL: https://issues.apache.org/jira/browse/SLING-6161
> Project: Sling
>  Issue Type: Task
>  Components: API
>Affects Versions: API 2.14.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: API 2.15.0
>
>
> With SLING-5909 a new behaviour has been introduced to Path.matches() which 
> supports matches a Path against a glob pattern.
> The attached test only convers a Path object with "/", but it is unclear what 
> the intend of this change actually is - and what the semantics is.
> The javadoc of matches() right now clearly states that the argument should be 
> a path, therefore glob pattern is not supported in that method.
> [~radu.cotescu] Could you please comment on the intended behaviour?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)