[jira] [Closed] (SLING-7348) Switch to OSGi annotation for Tracer bundle

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra closed SLING-7348.
--

> Switch to OSGi annotation for Tracer bundle
> ---
>
> Key: SLING-7348
> URL: https://issues.apache.org/jira/browse/SLING-7348
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.6
>
>
> Switch to official osgi annotations



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

[RESULT][VOTE] Release Apache Sling Log Tracer 1.0.6

[Chetan Mehrotra]

Hi,

The release passes with 4 binding +1 votes from: Stefan Seifert, Karl
Pauls, and Daniel Klco.

Chetan Mehrotra

[jira] [Assigned] (SLING-7313) ResourceResolverImpl#refresh should also refresh the internal resourceTyperesourceResolver

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-7313:
---

Assignee: Konrad Windszus

I applied the PR, lgtm. Thanks

> ResourceResolverImpl#refresh should also refresh the internal 
> resourceTyperesourceResolver
> --
>
> Key: SLING-7313
> URL: https://issues.apache.org/jira/browse/SLING-7313
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Julian Sedding
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Resolver 1.5.34
>
> Attachments: refresh-session.txt
>
>
> I noticed warning log messages due to long-lived Oak sessions (see 
> attachment) and traced them back to a long-lived service {{ResourceResolver}} 
> in the I18N code ({{JcrResourceBundleProvider}}). Care is taken to 
> periodically refresh this {{ResourceResolver}}, however, the {{#refresh()}} 
> call is not propagated to the internal {{resourceTypeResourceResolver}} used 
> by {{ResourceResolverImpl}} and thus a warning is logged.
> This could be solved by using short-lived RRs in the I18N code, but I think 
> we should also refresh the internal {{resourceTypeResourceResolver}} used by 
> {{ResourceResolverImpl}} when RR is refreshed.



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

[jira] [Resolved] (SLING-7313) ResourceResolverImpl#refresh should also refresh the internal resourceTyperesourceResolver

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-7313.
-
Resolution: Fixed

> ResourceResolverImpl#refresh should also refresh the internal 
> resourceTyperesourceResolver
> --
>
> Key: SLING-7313
> URL: https://issues.apache.org/jira/browse/SLING-7313
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Julian Sedding
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Resolver 1.5.34
>
> Attachments: refresh-session.txt
>
>
> I noticed warning log messages due to long-lived Oak sessions (see 
> attachment) and traced them back to a long-lived service {{ResourceResolver}} 
> in the I18N code ({{JcrResourceBundleProvider}}). Care is taken to 
> periodically refresh this {{ResourceResolver}}, however, the {{#refresh()}} 
> call is not propagated to the internal {{resourceTypeResourceResolver}} used 
> by {{ResourceResolverImpl}} and thus a warning is logged.
> This could be solved by using short-lived RRs in the I18N code, but I think 
> we should also refresh the internal {{resourceTypeResourceResolver}} used by 
> {{ResourceResolverImpl}} when RR is refreshed.



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

[jira] [Updated] (SLING-7313) ResourceResolverImpl#refresh should also refresh the internal resourceTyperesourceResolver

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-7313:

Fix Version/s: Resource Resolver 1.5.34

> ResourceResolverImpl#refresh should also refresh the internal 
> resourceTyperesourceResolver
> --
>
> Key: SLING-7313
> URL: https://issues.apache.org/jira/browse/SLING-7313
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Julian Sedding
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Resolver 1.5.34
>
> Attachments: refresh-session.txt
>
>
> I noticed warning log messages due to long-lived Oak sessions (see 
> attachment) and traced them back to a long-lived service {{ResourceResolver}} 
> in the I18N code ({{JcrResourceBundleProvider}}). Care is taken to 
> periodically refresh this {{ResourceResolver}}, however, the {{#refresh()}} 
> call is not propagated to the internal {{resourceTypeResourceResolver}} used 
> by {{ResourceResolverImpl}} and thus a warning is logged.
> This could be solved by using short-lived RRs in the I18N code, but I think 
> we should also refresh the internal {{resourceTypeResourceResolver}} used by 
> {{ResourceResolverImpl}} when RR is refreshed.



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

[jira] [Commented] (SLING-7313) ResourceResolverImpl#refresh should also refresh the internal resourceTyperesourceResolver

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-7313:
---

cziegeler closed pull request #1: SLING-7313 refresh the resource type resolver 
as well
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> ResourceResolverImpl#refresh should also refresh the internal 
> resourceTyperesourceResolver
> --
>
> Key: SLING-7313
> URL: https://issues.apache.org/jira/browse/SLING-7313
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Julian Sedding
>Priority: Minor
> Attachments: refresh-session.txt
>
>
> I noticed warning log messages due to long-lived Oak sessions (see 
> attachment) and traced them back to a long-lived service {{ResourceResolver}} 
> in the I18N code ({{JcrResourceBundleProvider}}). Care is taken to 
> periodically refresh this {{ResourceResolver}}, however, the {{#refresh()}} 
> call is not propagated to the internal {{resourceTypeResourceResolver}} used 
> by {{ResourceResolverImpl}} and thus a warning is logged.
> This could be solved by using short-lived RRs in the I18N code, but I think 
> we should also refresh the internal {{resourceTypeResourceResolver}} used by 
> {{ResourceResolverImpl}} when RR is refreshed.



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

[GitHub] cziegeler closed pull request #1: SLING-7313 refresh the resource type resolver as well

[GitBox]

cziegeler closed pull request #1: SLING-7313 refresh the resource type resolver 
as well
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [feature model] Format of text section - repoinit and others

[Carsten Ziegeler]

As soon as you have more than one file, packaging becomes a problem. How
do you easily distribute such a model, which files are needed, how do
you find them after unpacking etc.

Keep in mind, that repoinit is a Sling proprietary mechanism which is
not of general interest for an OSGi feature model. So I don't want to
complicate the general model for a small use case.

And one option should really be enough

Carsten


Dominik Süß wrote
> Hi,
> 
> I personally think 1 & 2 have their advantages - externalizing rather
> complex repoinit setups with dozens of statements might make sense to keep
> the feature model overall better readable. So I would personally opt for
> both options.
> 
> Cheers
> Dominik
> 
> On Mon, Jan 8, 2018 at 2:11 PM, Carsten Ziegeler 
> wrote:
> 
>> Hi,
>>
>> good point, I don't like the second option as I prefer having everything
>> in a single file. The third option would introduce a special format per
>> extension which then might need special rules/implementation for merging
>> two modules or handling inheritance/includes.
>>
>> Which leaves us with the first option :)
>>
>> I think parsing this is easy: if it's in array simply concat the values
>> and apply newlines in between. In the same way we could write out a text
>> value: we split the text by newlines and create an array out of it.
>>
>> Regards
>>
>> Carsten
>>
>>
>> Robert Munteanu wrote
>>> Hi,
>>>
>>> While working some more with the feature model I realized that text
>>> sections can not contain newlines - this is a limitation of JSON.
>>>
>>> This makes it very hard to work with repoinit sections. I end up with
>>> (literally) 10k characters on a single line. Diffs are going to be
>>> interesting with such formats :-)
>>>
>>> I think it would help adoption a lot if we have a more friendly format
>>> for text entries.
>>>
>>> One option would be to have lines stored as an array, e.g.
>>>
>>>   "repoinit:TEXT|false": [
>>>   "create path (sling:Folder) /libs",
>>>   "create path (sling:Folder) /apps",
>>>   "create path (sling:Folder) /tmp"
>>>   ]
>>>
>>> Not that nice, but it keeps the file self-contained.
>>>
>>> Another option would be to keep a secondary text file around and
>>> introduce a new field type, file:
>>>
>>>   "repoinit:FILE": "./repoinit.txt"
>>>
>>> This has the disadvantage of no longer having the configuration be
>>> self-contained, but on the other hand it's a text file, which the
>>> repoinit format was built for.
>>>
>>> The third option - for the sake of being complete - is to have a
>>> structured JSON format for repoint, but IMO that's overkill. Something
>>> like:
>>>
>>>   "repoinit": {
>>>   "paths": [
>>>   "/libs (sling:Folder)",
>>>   "/apps (sling:Folder)",
>>>   "/tmp (sling:Folder)"
>>>   ]
>>>}
>>>
>>> Thoughts? I think the feature model approach is great, but we need to
>>> improve on the usability of text sections.
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

RE: [VOTE] Accept donation of Resource Encryption module - SLING-7225

[Jason Bailey]

+1 non-binding

Awesome.

-Original Message-
From: Daniel Klco [mailto:dk...@apache.org] 
Sent: Tuesday, January 09, 2018 10:58 PM
To: dev@sling.apache.org
Subject: Re: [VOTE] Accept donation of Resource Encryption module - SLING-7225

EXTERNAL

+1

Though I agree that a thorough review of the implementation details by a 
security expert would be required before the initial release.

On Tue, Jan 9, 2018 at 7:42 AM, Stefan Seifert 
wrote:

> +1
>
> i think there was no thorough review of the implementation details/API 
> yet, but it is a very good starting point and it can be polished 
> further after the contribution (and before the first release).
>
> stefan
>
>
> >-Original Message-
> >From: Robert Munteanu [mailto:romb...@apache.org]
> >Sent: Tuesday, January 9, 2018 1:43 PM
> >To: dev@sling.apache.org
> >Subject: [VOTE] Accept donation of Resource Encryption module - 
> >SLING-7225
> >
> >Hi,
> >
> >Please vote to accept the donation of the Resource Encryption module 
> >described in SLING-7225 [1].
> >
> >This majority vote is open for at least 72 hours.
> >
> >Thanks,
> >
> >Robert
> >
> >[1]: https://issues.apache.org/jira/browse/SLING-7255
>
>

Re: [feature model] Format of text section - repoinit and others

[Dominik Süß]

Hi,

I personally think 1 & 2 have their advantages - externalizing rather
complex repoinit setups with dozens of statements might make sense to keep
the feature model overall better readable. So I would personally opt for
both options.

Cheers
Dominik

On Mon, Jan 8, 2018 at 2:11 PM, Carsten Ziegeler 
wrote:

> Hi,
>
> good point, I don't like the second option as I prefer having everything
> in a single file. The third option would introduce a special format per
> extension which then might need special rules/implementation for merging
> two modules or handling inheritance/includes.
>
> Which leaves us with the first option :)
>
> I think parsing this is easy: if it's in array simply concat the values
> and apply newlines in between. In the same way we could write out a text
> value: we split the text by newlines and create an array out of it.
>
> Regards
>
> Carsten
>
>
> Robert Munteanu wrote
> > Hi,
> >
> > While working some more with the feature model I realized that text
> > sections can not contain newlines - this is a limitation of JSON.
> >
> > This makes it very hard to work with repoinit sections. I end up with
> > (literally) 10k characters on a single line. Diffs are going to be
> > interesting with such formats :-)
> >
> > I think it would help adoption a lot if we have a more friendly format
> > for text entries.
> >
> > One option would be to have lines stored as an array, e.g.
> >
> >   "repoinit:TEXT|false": [
> >   "create path (sling:Folder) /libs",
> >   "create path (sling:Folder) /apps",
> >   "create path (sling:Folder) /tmp"
> >   ]
> >
> > Not that nice, but it keeps the file self-contained.
> >
> > Another option would be to keep a secondary text file around and
> > introduce a new field type, file:
> >
> >   "repoinit:FILE": "./repoinit.txt"
> >
> > This has the disadvantage of no longer having the configuration be
> > self-contained, but on the other hand it's a text file, which the
> > repoinit format was built for.
> >
> > The third option - for the sake of being complete - is to have a
> > structured JSON format for repoint, but IMO that's overkill. Something
> > like:
> >
> >   "repoinit": {
> >   "paths": [
> >   "/libs (sling:Folder)",
> >   "/apps (sling:Folder)",
> >   "/tmp (sling:Folder)"
> >   ]
> >}
> >
> > Thoughts? I think the feature model approach is great, but we need to
> > improve on the usability of text sections.
> >
> > Thanks,
> >
> > Robert
> >
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Resolved] (SLING-7371) ResourceProviderTracker.updateProviderContext can cause ConcurrentModificationException

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-7371.
---
Resolution: Fixed

Done.

> ResourceProviderTracker.updateProviderContext can cause 
> ConcurrentModificationException
> ---
>
> Key: SLING-7371
> URL: https://issues.apache.org/jira/browse/SLING-7371
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.34
>
>
> The updateProviderContext method accesses the "handler" member outside of a 
> "synchronized (this.handler)" block which can lead to a 
> ConcurrentModificationException similar to:
> {noformat}
> java.util.ConcurrentModificationException: null
>   at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.updateProviderContext(ResourceProviderTracker.java:484)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:352)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:190)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> {noformat}



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

[jira] [Commented] (SLING-7371) ResourceProviderTracker.updateProviderContext can cause ConcurrentModificationException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-7371:
---

karlpauls closed pull request #2: SLING-7371: synchronize access to the 
handlers inside ResourceProvide…
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/2
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> ResourceProviderTracker.updateProviderContext can cause 
> ConcurrentModificationException
> ---
>
> Key: SLING-7371
> URL: https://issues.apache.org/jira/browse/SLING-7371
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.34
>
>
> The updateProviderContext method accesses the "handler" member outside of a 
> "synchronized (this.handler)" block which can lead to a 
> ConcurrentModificationException similar to:
> {noformat}
> java.util.ConcurrentModificationException: null
>   at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.updateProviderContext(ResourceProviderTracker.java:484)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:352)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:190)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> {noformat}



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

[GitHub] karlpauls closed pull request #2: SLING-7371: synchronize access to the handlers inside ResourceProvide?

[GitBox]

karlpauls closed pull request #2: SLING-7371: synchronize access to the 
handlers inside ResourceProvide?
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/2
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SLING-7334) slingstart-maven-plugin: DependencyLifecycleParticipant must only consider Maven modules leveraging the same version of slingstart-m-p

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7334:


[~olli] Can you check the aggregator by upgrading to the latest SNAPSHOT?

> slingstart-maven-plugin: DependencyLifecycleParticipant must only consider 
> Maven modules leveraging the same version of slingstart-m-p
> --
>
> Key: SLING-7334
> URL: https://issues.apache.org/jira/browse/SLING-7334
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.7.14
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.7.16
>
>
> The {{DependencyLifecycleParticipant}} is always being active for all module 
> leveraging the plugin (in any version). That might lead to problems, when 
> certain modules rely on a newer version of that extension. This is e.g. the 
> case for Validation Core which breaks aggregator builds after switching from 
> {{org.apache.sling.testing.paxexam}} to {{slingstart-maven-plugin}} 
> (SLING-7298) for integration tests. This module relies on version 1.7.14 of 
> the {{slingstart-maven-plugin}} and breaks with older versions.
> The {{slingstart-maven-plugin}} itself is not part of aggregator project 
> (MNG-1911) though.
> {noformat}
> [ERROR] Internal error: java.lang.IllegalArgumentException: Unable to resolve 
> dependency: mvn:org.apache.sling/org.apache.sling.validation.core/LATEST -> 
> [Help 1]
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.IllegalArgumentException: Unable to resolve dependency: 
> mvn:org.apache.sling/org.apache.sling.validation.core/LATEST
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:122)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:356)
> Caused by: java.lang.IllegalArgumentException: Unable to resolve dependency: 
> mvn:org.apache.sling/org.apache.sling.validation.core/LATEST
> at org.apache.sling.maven.slingstart.PomArtifactVersionResolver.resolve 
> (PomArtifactVersionResolver.java:63)
> at 
> org.apache.sling.provisioning.model.ModelResolveUtility.resolveArtifactVersion
>  (ModelResolveUtility.java:94)
> at 
> org.apache.sling.provisioning.model.EffectiveModelProcessor.processArtifact 
> (EffectiveModelProcessor.java:51)
> at org.apache.sling.provisioning.model.ModelProcessor.process 
> (ModelProcessor.java:62)
> at org.apache.sling.provisioning.model.ModelUtility.getEffectiveModel 
> (ModelUtility.java:155)
> at org.apache.sling.maven.slingstart.ModelPreprocessor.addDependencies 
> (ModelPreprocessor.java:164)
> at org.apache.sling.maven.slingstart.ModelPreprocessor.addDependencies 
> (ModelPreprocessor.java:88)
> at 
> org.apache.sling.maven.slingstart.DependencyLifecycleParticipant.afterProjectsRead
>  (DependencyLifecycleParticipant.java:78)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:267)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:229)
> at 

Re: [VOTE] Release Apache Sling Resource Merger 1.3.6

[Daniel Klco]

+1

On Wed, Jan 10, 2018 at 4:03 AM, Robert Munteanu  wrote:

> On Wed, 2018-01-10 at 11:52 +0100, Carsten Ziegeler wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

Re: Where do we put new git modules?

[Bertrand Delacretaz]

On Wed, Jan 10, 2018 at 12:39 PM, Robert Munteanu  wrote:
> ...Unless strictly needed, I would suggest that we import just the latest
> state, not the repository history...

+1, but as Stefan notes, once imported the history is important and we
shouldn't lose it - for which your copy-with script mechanism helps.

-Bertrand

[jira] [Commented] (SLING-7332) Fix typo in org.apache.sling.cransktart.test.model

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-7332:
-

[~rombert], I had to update sling-aggregator before running the seed job.

> Fix typo in org.apache.sling.cransktart.test.model
> --
>
> Key: SLING-7332
> URL: https://issues.apache.org/jira/browse/SLING-7332
> Project: Sling
>  Issue Type: Bug
>  Components: Crankstart
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Crankstart Launcher 2.0.0
>
>
> Maven {{artifactId}} (and repository name) should be 
> {{org.apache.sling.crankstart.test.model}} 
> ({{sling-org-apache-sling-crankstart-test-model}}).
> [~rombert], can we rename Git repos?



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

[jira] [Resolved] (SLING-7332) Fix typo in org.apache.sling.cransktart.test.model

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-7332.
-
Resolution: Fixed

> Fix typo in org.apache.sling.cransktart.test.model
> --
>
> Key: SLING-7332
> URL: https://issues.apache.org/jira/browse/SLING-7332
> Project: Sling
>  Issue Type: Bug
>  Components: Crankstart
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Crankstart Launcher 2.0.0
>
>
> Maven {{artifactId}} (and repository name) should be 
> {{org.apache.sling.crankstart.test.model}} 
> ({{sling-org-apache-sling-crankstart-test-model}}).
> [~rombert], can we rename Git repos?



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

Re: Service User OSGi Console

[Robert Munteanu]

On Tue, 2018-01-09 at 22:00 -0800, Daniel Klco wrote:
> Makes sense and I was kind of suspecting this would be the case. To
> enable
> the ServiceUser Console to work in a separate bundle though, I do
> need to
> make the Mapping class public and expose the getActiveMappings method
> on
> the ServiceUserMapper interface as shown below:
> 
> https://github.com/apache/sling-org-apache-sling-serviceusermapper/co
> mpare/master...klcodanr:master
> 
> Does that pose any issues? If not I'll go ahead and start on getting
> Service User Mapper 1.4.0 and adding the Service User Console bundle.
> I'm
> assuming this is okay from a naming perspective:
> 
>  - Git Repo Name: sling-org-apache-sling-serviceuser-console
>  - artifactId: org.apache.sling.serviceuser.console
>  - name: Apache Sling Service User Console


That looks mostly ok to me. I would name it 'webconsole' though instead
of 'console', to make it 100% clear.

Other than that, I don't think you need the profile addition in the
pom.xml, it should be inherited from the parent pom.

Thanks,

Robert

Re: [VOTE] Release Apache Sling Resource Merger 1.3.6

[Robert Munteanu]

On Wed, 2018-01-10 at 11:52 +0100, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: Where do we put new git modules?

[Robert Munteanu]

On Tue, 2018-01-09 at 16:55 +0100, Bertrand Delacretaz wrote:
> On Tue, Jan 9, 2018 at 4:48 PM, Stefan Seifert  e> wrote:
> > ...it makes it more difficult if the contribution was already
> > developed in a standalone git
> > repo outside the ASF and perhaps there is already a commit history
> > we want preserve...
> 
> I don't think we are interested in the history of those donations in
> general.
> 
> If a special case needs that we can always handle it in a different
> way.

This got me thinking for a little bit. Donations were always done as as
source code dumps, and that's what was voted on. We did not vote on
histories, and a case can be made that source code histories are less
safe to import, as we don't review the whole history, but instead the
latest state - the patch.

Unless strictly needed, I would suggest that we import just the latest
state, not the repository history.

Robert

Re: Where do we put new git modules?

[Robert Munteanu]

On Tue, 2018-01-09 at 15:48 +, Stefan Seifert wrote:
> > On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu  > > wrote:
> > > ...- place it in the whiteboard and move it to a proper repo
> > > before its
> > > first release, with the release manager proposing a name..
> > 
> > +1, it's simple and leaves time to make a proper naming decision.
> > 
> > -Bertrand
> 
> yes, this would avoid making the naming decision early, or even the
> decision to release it at all.
> on the other hand it makes it more difficult if the contribution was
> already developed in a standalone git repo outside the ASF and
> perhaps there is already a commit history we want preserve - getting
> this into the whiteboard master branch in a subdirectory is
> complicated.

We can both import a directory with history and export a directory with
history using Git. Some scripting is required, but I can take care of
that with the first import, documentation included.

The export part is mostly covered in [1] as we took care of the SVN →
Git migration.

The import part is much simpler IIRC, basically 

1. git format-patch on the 'source' repo to generate patches for all
commmits
2. git am --directory=new-module-dir on the 'target' repo to apply the
patches to the 'new-module-dir' directory.

Thanks,

Robert

[1]: https://github.com/apache/sling-tooling-scm

Re: [VOTE] Release Apache Sling Resource Merger 1.3.6

[Carsten Ziegeler]

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

[VOTE] Release Apache Sling Resource Merger 1.3.6

[Carsten Ziegeler]

Hi,

we fixed one issue in this release:
https://issues.apache.org/jira/browse/SLING-7366

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

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

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

Re: Sling to Solr integration using Sling Content Distribution

[Tommaso Teofili]

+1

thanks a lot Dirk for your contributions (4 PRs so far!). This sounds like
a very interesting use case for Sling and SCD.

Regards,
Tommaso



Il giorno mar 9 gen 2018 alle ore 02:22 Daniel Klco 
ha scritto:

> This is a great idea! I could see this as a use case for a number of
> different integrations and an example would be very helpful for anyone
> looking to do this.
>
> On Mon, Jan 8, 2018 at 1:44 PM, Stefan Seifert 
> wrote:
>
> > hello dirk.
> >
> > i think such a feature would be very useful. integration of an external
> > search engine on a "higher level" than the oak-level search integration
> is
> > a common use case in our projects as well. it's important to be quite
> > flexible what is indexed and what not and how it's indexed - for best
> match
> > of the business requirements and the special features of the targeted
> > search engine.
> >
> > stefan
> >
> > >-Original Message-
> > >From: Dirk Rudolph [mailto:dirk.rudo...@netcentric.biz]
> > >Sent: Monday, January 8, 2018 4:45 PM
> > >To: dev@sling.apache.org
> > >Subject: Sling to Solr integration using Sling Content Distribution
> > >
> > >Hi devs,
> > >
> > >Recently I was evaluating if it is easily possible to integrate Sling
> into
> > >Solr using Sling Content Distributions and made some great progress
> here:
> > >
> > >https://github.com/Buuhuu/sling-content-distribution-solr
> > >
> > >
> > >The repository explains the goal, the why and who also giving
> instructions
> > >on how to use it. To sum it up a bit:
> > >
> > >- SCD’s features map perfectly fine to the requirements when integrating
> > >into solr
> > >- It enables us to ingest content on business perspective (not technical
> > >perspective as with Oak’s internal indexes)
> > >- It’s flexible (thanks for that already :)
> > >
> > >Though there are some things that require a bit of attention to make it
> > >work out of the box. I opened a couple of issues for that:
> > >
> > >SLING-7357
> > >SLING-7358
> > >SLING-7359
> > >SLING-7360
> > >SLING-7364
> > >
> > >And made proposals accordingly (not for the last one as I want to
> discuss
> > >that first)
> > >
> > >So my general question is:
> > >
> > >Is integrating Sling into Solr (or potentially any other kind of system
> > >that offers APIs to do so) a valid and envisaged use-case for Sling
> > Content
> > >Distribution? And if so would it make sense to implement a module for
> lets
> > >say Solr as example directly in Sling?
> > >
> > >If so I would volunteer to propose something for that but I think
> flexibly
> > >integrating Sling as framework for any kind of content driven web
> > >applications into Solr as enterprise search application would be a nice
> > >feature to offer.
> > >
> > >Thanks for any kind of feedback,
> > >
> > >/Dirk
> >
>

[jira] [Resolved] (SLING-7366) Sling Resource Merger: Order Before Property not being honored during resource merging

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-7366.
-
Resolution: Fixed

Thanks for the PR [~rishimehta]. It's applied

> Sling Resource Merger: Order Before Property not being honored during 
> resource merging
> --
>
> Key: SLING-7366
> URL: https://issues.apache.org/jira/browse/SLING-7366
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.3.4
>Reporter: Rishi Mehta
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Merger 1.3.6
>
>
> Due to the changes in https://issues.apache.org/jira/browse/SLING-6956, the 
> *orderBefore* property in resource is not honored correctly during resource 
> merging.



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

[jira] [Updated] (SLING-7366) Sling Resource Merger: Order Before Property not being honored during resource merging

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-7366:

Fix Version/s: Resource Merger 1.3.6

> Sling Resource Merger: Order Before Property not being honored during 
> resource merging
> --
>
> Key: SLING-7366
> URL: https://issues.apache.org/jira/browse/SLING-7366
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.3.4
>Reporter: Rishi Mehta
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Merger 1.3.6
>
>
> Due to the changes in https://issues.apache.org/jira/browse/SLING-6956, the 
> *orderBefore* property in resource is not honored correctly during resource 
> merging.



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

[jira] [Assigned] (SLING-7366) Sling Resource Merger: Order Before Property not being honored during resource merging

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-7366:
---

Assignee: Carsten Ziegeler

> Sling Resource Merger: Order Before Property not being honored during 
> resource merging
> --
>
> Key: SLING-7366
> URL: https://issues.apache.org/jira/browse/SLING-7366
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.3.4
>Reporter: Rishi Mehta
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Merger 1.3.6
>
>
> Due to the changes in https://issues.apache.org/jira/browse/SLING-6956, the 
> *orderBefore* property in resource is not honored correctly during resource 
> merging.



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

[jira] [Commented] (SLING-7366) Sling Resource Merger: Order Before Property not being honored during resource merging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-7366:
---

cziegeler closed pull request #1: SLING-7366 OrderBefore property not being 
honored during resource mer…
URL: https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/1
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
 
b/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
index 8cf6d2b..3ba9c9e 100644
--- 
a/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
+++ 
b/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
@@ -378,7 +378,6 @@ public Resource getResource(final ResolveContext ctx, 
final String path, f
 if (orderBeforeIndex > -1) {
 candidates.add(orderBeforeIndex, holder);
 candidates.remove(candidates.size() - 1);
-previousChildPositionInCandidateList = 
orderBeforeIndex;
 } else {
 // or reorder because overlaid resource has a 
different order
 if (childPositionInCandidateList != -1 && 
previousChildPositionInCandidateList != -1) {
diff --git 
a/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
 
b/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
index c213d99..07c1904 100644
--- 
a/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
+++ 
b/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
@@ -402,12 +402,20 @@ public void testOrderBeingModifiedThroughOrderBefore() 
throws PersistenceExcepti
 MockHelper.create(this.resolver)
 .resource("/apps/base/child1")
 .resource("/apps/base/child2")
-
.resource("/apps/overlay/child3").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+.resource("/apps/base/child3")
+.resource("/apps/base/child4")
+
.resource("/apps/overlay/child5").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+
.resource("/apps/overlay/child6").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+
.resource("/apps/overlay/child7").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child4")
+
.resource("/apps/overlay/child8").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child3")
+
.resource("/apps/overlay/child9").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child3")
+.resource("/apps/overlay/child10")
+.resource("/apps/overlay/child3")
 .commit();
 Resource mergedResource = this.provider.getResource(ctx, "/merged", 
ResourceContext.EMPTY_CONTEXT, null);
 // convert the iterator returned by list children into an iterable (to 
be able to perform some tests)
 IteratorIterable iterable = new 
IteratorIterable(provider.listChildren(ctx, mergedResource), true);
 
-Assert.assertThat(iterable, 
Matchers.contains(ResourceMatchers.name("child1"),ResourceMatchers.name("child3"),
 ResourceMatchers.name("child2")));
+Assert.assertThat(iterable, 
Matchers.contains(ResourceMatchers.name("child1"),ResourceMatchers.name("child5"),
 ResourceMatchers.name("child6"), ResourceMatchers.name("child2"), 
ResourceMatchers.name("child8"),ResourceMatchers.name("child9"), 
ResourceMatchers.name("child7"),ResourceMatchers.name("child4"),ResourceMatchers.name("child10"),ResourceMatchers.name("child3")));
 }
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Sling Resource Merger: Order Before Property not being honored during 
> resource merging
> --
>
> Key: SLING-7366
> URL: https://issues.apache.org/jira/browse/SLING-7366
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.3.4
>Reporter: Rishi Mehta
>Priority: Critical
>
> Due to the changes in https://issues.apache.org/jira/browse/SLING-6956, the 
> *orderBefore* property in resource is not honored correctly during resource 
> merging.

[GitHub] cziegeler closed pull request #1: SLING-7366 OrderBefore property not being honored during resource mer?

[GitBox]

cziegeler closed pull request #1: SLING-7366 OrderBefore property not being 
honored during resource mer?
URL: https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/1
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
 
b/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
index 8cf6d2b..3ba9c9e 100644
--- 
a/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
+++ 
b/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java
@@ -378,7 +378,6 @@ public Resource getResource(final ResolveContext ctx, 
final String path, f
 if (orderBeforeIndex > -1) {
 candidates.add(orderBeforeIndex, holder);
 candidates.remove(candidates.size() - 1);
-previousChildPositionInCandidateList = 
orderBeforeIndex;
 } else {
 // or reorder because overlaid resource has a 
different order
 if (childPositionInCandidateList != -1 && 
previousChildPositionInCandidateList != -1) {
diff --git 
a/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
 
b/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
index c213d99..07c1904 100644
--- 
a/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
+++ 
b/src/test/java/org/apache/sling/resourcemerger/impl/CommonMergedResourceProviderTest.java
@@ -402,12 +402,20 @@ public void testOrderBeingModifiedThroughOrderBefore() 
throws PersistenceExcepti
 MockHelper.create(this.resolver)
 .resource("/apps/base/child1")
 .resource("/apps/base/child2")
-
.resource("/apps/overlay/child3").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+.resource("/apps/base/child3")
+.resource("/apps/base/child4")
+
.resource("/apps/overlay/child5").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+
.resource("/apps/overlay/child6").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child2")
+
.resource("/apps/overlay/child7").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child4")
+
.resource("/apps/overlay/child8").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child3")
+
.resource("/apps/overlay/child9").p(MergedResourceConstants.PN_ORDER_BEFORE, 
"child3")
+.resource("/apps/overlay/child10")
+.resource("/apps/overlay/child3")
 .commit();
 Resource mergedResource = this.provider.getResource(ctx, "/merged", 
ResourceContext.EMPTY_CONTEXT, null);
 // convert the iterator returned by list children into an iterable (to 
be able to perform some tests)
 IteratorIterable iterable = new 
IteratorIterable(provider.listChildren(ctx, mergedResource), true);
 
-Assert.assertThat(iterable, 
Matchers.contains(ResourceMatchers.name("child1"),ResourceMatchers.name("child3"),
 ResourceMatchers.name("child2")));
+Assert.assertThat(iterable, 
Matchers.contains(ResourceMatchers.name("child1"),ResourceMatchers.name("child5"),
 ResourceMatchers.name("child6"), ResourceMatchers.name("child2"), 
ResourceMatchers.name("child8"),ResourceMatchers.name("child9"), 
ResourceMatchers.name("child7"),ResourceMatchers.name("child4"),ResourceMatchers.name("child10"),ResourceMatchers.name("child3")));
 }
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-7360.

Resolution: Fixed
  Assignee: Dirk Rudolph

> Support creation of DistributionPackages for delete by 
> DistributionContentSerializer
> 
>
> Key: SLING-7360
> URL: https://issues.apache.org/jira/browse/SLING-7360
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> For the integration into systems or then sling, that support 
> creation/deletion as part of their API [1], we can implement a 
> {{DistributionContentSerializer}} writing the format the API expects. That 
> currently works well for creation but not for deletion because both 
> {{FileDistributionPackageBuilder}} and {{ResourceDistributionPackageBuilder}} 
> inherit from {{AbstractDistributionPackageBuilder}} which [returns a 
> SimpleDistributionPackage|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/AbstractDistributionPackageBuilder.java#L72]
>  for {{DistributionRequestType.DELETE}}. 
> The other system's API might expect a different format then the one written 
> by {{SimpleDistributionPackage}} so it would be create if it would be 
> possible to delegate the creation of a deletion package to the serializer as 
> well, in case the serializer supports that.
> [1] 
> https://lucene.apache.org/solr/guide/7_2/uploading-data-with-index-handlers.html



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

[jira] [Commented] (SLING-7371) ResourceProviderTracker.updateProviderContext can cause ConcurrentModificationException

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-7371:
---

[~cziegeler], I did see that but it is synchronizing on the same member - 
hence, it shouldn't do any harm and it seemed saver to synchronize inside the 
method to avoid making the same mistake (calling it without the lock) at a 
later point. But I don't fell strongly about it either way - I'll commit it 
synchronizing the call in activate. Thanks!

> ResourceProviderTracker.updateProviderContext can cause 
> ConcurrentModificationException
> ---
>
> Key: SLING-7371
> URL: https://issues.apache.org/jira/browse/SLING-7371
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.34
>
>
> The updateProviderContext method accesses the "handler" member outside of a 
> "synchronized (this.handler)" block which can lead to a 
> ConcurrentModificationException similar to:
> {noformat}
> java.util.ConcurrentModificationException: null
>   at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.updateProviderContext(ResourceProviderTracker.java:484)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:352)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:190)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> {noformat}



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

[jira] [Comment Edited] (SLING-7371) ResourceProviderTracker.updateProviderContext can cause ConcurrentModificationException

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler edited comment on SLING-7371 at 1/10/18 8:15 AM:
--

[~kpauls] No :) updateProviderContext is called from two places, one of them is 
already using a synchronized block, the other - activate is not. The  fix is to 
put the sync around the call to updateProviderContext in activate.


was (Author: cziegeler):
[~pauls] No :) updateProviderContext is called from two places, one of them is 
already using a synchronized block, the other - activate is not. The  fix is to 
put the sync around the call to updateProviderContext in activate.

> ResourceProviderTracker.updateProviderContext can cause 
> ConcurrentModificationException
> ---
>
> Key: SLING-7371
> URL: https://issues.apache.org/jira/browse/SLING-7371
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.34
>
>
> The updateProviderContext method accesses the "handler" member outside of a 
> "synchronized (this.handler)" block which can lead to a 
> ConcurrentModificationException similar to:
> {noformat}
> java.util.ConcurrentModificationException: null
>   at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.updateProviderContext(ResourceProviderTracker.java:484)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:352)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:190)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> {noformat}



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

[jira] [Commented] (SLING-7371) ResourceProviderTracker.updateProviderContext can cause ConcurrentModificationException

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7371:
-

[~pauls] No :) updateProviderContext is called from two places, one of them is 
already using a synchronized block, the other - activate is not. The  fix is to 
put the sync around the call to updateProviderContext in activate.

> ResourceProviderTracker.updateProviderContext can cause 
> ConcurrentModificationException
> ---
>
> Key: SLING-7371
> URL: https://issues.apache.org/jira/browse/SLING-7371
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.32
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.34
>
>
> The updateProviderContext method accesses the "handler" member outside of a 
> "synchronized (this.handler)" block which can lead to a 
> ConcurrentModificationException similar to:
> {noformat}
> java.util.ConcurrentModificationException: null
>   at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.updateProviderContext(ResourceProviderTracker.java:484)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:352)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:190)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>   at 
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> {noformat}



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

[jira] [Resolved] (SLING-7370) File system resource provider may never recover from JSON/XML syntax errors

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-7370.
---
Resolution: Fixed
  Assignee: Julian Sedding

Fixed with commit 
[6790568|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-fsresource.git;a=commitdiff;h=6790568].

> File system resource provider may never recover from JSON/XML syntax errors
> ---
>
> Key: SLING-7370
> URL: https://issues.apache.org/jira/browse/SLING-7370
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: File System Resource Provider 2.1.8
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: File System Resource Provider 2.1.10
>
> Attachments: SLING-7370.patch
>
>
> While using the file system resource provider in a development scenario, with 
> sample content in JSON format, it turned out that the resource provider never 
> recovered from a syntax error in a JSON file, even after the error was fixed. 
> Only after restarting the bundle the resource was ok again. The same 
> behaviour was then also verified with the FileVault XML format.
> The scenario was observed on a Sling system with multiple listeners for 
> resource change events, which access the changed resource right after the 
> change. It seems that there is a race in the way {{FileMonitor}} updates the 
> {{ContentFileCache}} ans sends events.
> Sending the events after removing the cache-entry seems to fix the problem.



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