[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-3524:
--

Note that use of {{ResourceResolverFactory.USER_IMPERSONATION}} (to self) does 
not work either, since the 
[JcrResourceProviderFactory|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L364]
 prevents from impersonating itself and returns the original session.

I think the problem is that the 
JcrResourceProviderFactory.getResourceProviderInternal() method that handles 
authentication info, is designed for an initial login (resource resolver 
creation). A clone has different semantics (such as avoiding a shared session), 
so this likely needs a separate code path.

> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was 
> created by passing an existing session using 
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of 
> the resource resolver to pass into a new, separate thread, and use 
> {{ResourceResolver.clone(null)}}, you will actually share the session, but 
> this is not obvious. The problem is that a JCR session cannot be shared 
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to 
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I 
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource 
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return 
> a session that impersonated itself, abstracting this from the resource 
> resolver user. Additionally, it might be worth looking that clone always 
> returns a new session, unless specifically stated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: ResourceResolver.clone(null) sharing same JCR session?

[Alexander Klimetschek]

On 25.04.2014, at 12:43, Alexander Klimetschek  wrote:

> Which is A LOT of boilerplate given there already is a clone() method. It is 
> not so much if using the USER_IMPERSONATION

Using USER_IMPERSONATION like this

final ResourceResolver clonedResolver = resolver.clone(new 
HashMap() {{
put(ResourceResolverFactory.USER_IMPERSONATION, 
resolver.getUserID());
}});

does NOT work, as the JcrResourceProviderFactory tries to be clever and avoids 
self-impersonation [1]. It reuses the original session :(

[1] 
https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L364

Cheers,
Alex

[jira] [Created] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

[Alexander Klimetschek (JIRA)]

Alexander Klimetschek created SLING-3524:


 Summary: ResourceResolver.clone(null) should not share the same 
JCR session
 Key: SLING-3524
 URL: https://issues.apache.org/jira/browse/SLING-3524
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Alexander Klimetschek


{{ResourceResolver.clone()}} will reuse the same JCR session in case it was 
created by passing an existing session using 
{{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of 
the resource resolver to pass into a new, separate thread, and use 
{{ResourceResolver.clone(null)}}, you will actually share the session, but this 
is not obvious. The problem is that a JCR session cannot be shared across 
threads.

The javadocs of clone() say "the same credential data is used as was used to 
create this instance".

There are a few problems with this:
- seeing the session object itself as "credential data" is unintuitive
- in my code, I have no idea what the original credential data was, so I don't 
know what kind of credential data it was to make the right decision
- since sharing a JCR session is to be avoided at all times, the resource 
resolver should prevent one from this

A solution would be if a plain {{ResourceResolver.clone(null)}} would return a 
session that impersonated itself, abstracting this from the resource resolver 
user. Additionally, it might be worth looking that clone always returns a new 
session, unless specifically stated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: ResourceResolver.clone(null) sharing same JCR session?

[Alexander Klimetschek]

I wanted to get some opinions on this first. Created 
https://issues.apache.org/jira/browse/SLING-3524

Cheers,
Alex

On 27.04.2014, at 04:43, Carsten Ziegeler  wrote:

> Well, I'm just stating the docs, feel free to open an issue to get this
> changed.
> 
> Thanks
> Carsten
> 
> 
> 2014-04-25 21:43 GMT+02:00 Alexander Klimetschek :
> 
>> On 25.04.2014, at 00:21, Carsten Ziegeler  wrote:
>> 
>>> The documentation of clone clearly states that if "null" is passed in:
>> "the
>>> same credential data is used as was used to create this instance." which
>> in
>>> turn means, if the initlal resolver was created based on a session, this
>>> one will share the session.
>> 
>> There are a few problems with this:
>> - seeing the session object itself as "credential data" is unintuitive
>> - in my code, I have no idea what the original credential data was, so I
>> don't know what kind of credential data it was to make the right decision
>> - since sharing a JCR session is to be avoided at all times, the resource
>> resolver should prevent one from this
>> 
>> Are there any cases where you want a cloned resolver to share the session?
>> 
>>> So in your case, you have to create a new session and pass this into the
>>> clone method - or you can also call the resource resolver factory
>> directly.
>> 
>> Which is A LOT of boilerplate given there already is a clone() method. It
>> is not so much if using the USER_IMPERSONATION, but still, clone(null)
>> would be great to reflect a session clone = impersonate itself.
>> 
>> Cheers,
>> Alex
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> cziege...@apache.org

Jenkins build is still unstable: sling-trunk-1.6 #2109

[Apache Jenkins Server]

See 

[jira] [Assigned] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports

[Oliver Lietz (JIRA)]

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

Oliver Lietz reassigned SLING-3114:
---

Assignee: Oliver Lietz

> DefaultContentImporter should guard against a closed InputStream on system 
> view imports
> ---
>
> Key: SLING-3114
> URL: https://issues.apache.org/jira/browse/SLING-3114
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Alex Parvulescu
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: JCR ContentLoader 2.1.8
>
>
> For the special case of system view imports the null check [0] fails to take 
> into account the fact that the input stream is now closed (twice even [1], 
> [2]).
> This means that if something happened and the import did not go throught 
> (hence the _null_ node), the code will continue and fail later (line 99) with 
> a cryptic message: _java.io.IOException: Stream Closed_ [3]
> My proposal (no patch) is to add an else clause with a warn log and a return 
> statement.
> [0] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
> [1] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
> [2] 
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
> [3]
> {noformat}
> Caused by: java.io.IOException: Stream Closed
>   at java.io.FileInputStream.available(Native Method)
>   at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
>   at 
> org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
>   at 
> org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #2109

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2109

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 #480

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #480

[Apache Jenkins Server]

See 

Re: [VOTE] Release Apache Sling discovery.impl 1.0.8

[Ian Boston]

+1
Ian

On 28 April 2014 08:59, Stefan Egli  wrote:
> Hi,
>
> We'd need one more binding vote here.
>
> Thanks,
> Stefan
>
> On 4/22/14 12:19 PM, "Stefan Egli"  wrote:
>
>>Hi,
>>
>>We solved 1 issue in this release:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12326702
>>
>>Staging repository:
>>https://repository.apache.org/content/repositories/orgapachesling-1050/
>>
>>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 1050 /tmp/sling-staging
>>
>>Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>>This majority vote is open for at least 72 hours.
>>
>>Cheers,
>>Stefan
>

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #479

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 #479

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 #2108

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #2108

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #2108

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3474) Concurrent modification exception in installer

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3474:
-

Actually the underlying problem is the same as described in SLING-3522.

> Concurrent modification exception in installer
> --
>
> Key: SLING-3474
> URL: https://issues.apache.org/jira/browse/SLING-3474
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.5.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.5.2
>
>
> The following exception might occur:
> 12.03.2014 23:21:49.899 *WARN* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.engine.impl.auth.SlingAuthenticator)] 
> org.apache.sling.installer.core.impl.PersistentResourceList Unable to save 
> persistent list: null
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
> at java.util.HashMap$EntryIterator.next(HashMap.java:966)
> at java.util.HashMap$EntryIterator.next(HashMap.java:964)
> at java.util.HashMap.writeObject(HashMap.java:1131)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1495)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> at 
> org.apache.sling.installer.core.impl.PersistentResourceList.save(PersistentResourceList.java:166)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.resourceAddedOrUpdated(OsgiInstallerImpl.java:965)
> at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.configurationEvent(ConfigTaskCreator.java:138)
> at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:744)
> While the installer works under the assumption that only the main thread can 
> modify the installer state, the writeback mechanism can actually also change 
> and persists state (as seen above). Therefore the code needs to be guarded 
> against concurrent access.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3522:
-

I've committed a first simple potential fix in rev 1590644

> NPE on startup in ChangeStateTask.getSortKey
> 
>
> Key: SLING-3522
> URL: https://issues.apache.org/jira/browse/SLING-3522
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.5.0
>Reporter: Philipp Marx
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.5.2
>
>
> ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
> whereas getResource() might return null.
> I tracked this down on my system to be a concurrency issue where the 
> ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
> update event. Since the state is now INSTALLED getResource() will return null 
> since it is checking for resource in state UNINSTALL oder INSTALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3523) ResourceResolverImpl.mangleNamespace and unmangleNamespaces behave differently

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-3523:
--

 Summary: ResourceResolverImpl.mangleNamespace and 
unmangleNamespaces behave differently
 Key: SLING-3523
 URL: https://issues.apache.org/jira/browse/SLING-3523
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Konrad Windszus


Currently everything which smells like a namespace is automatically mangled 
during the call of ResourceResolver.map. But only registered namespaces are 
unmangled automatically during ResourceResolver.resolve. This should be fixed, 
so that mangling an arbitrary string and afterwards unmangling that, should 
always return the original string.

You can see the according code in 
https://fisheye6.atlassian.com/browse/~br=trunk/sling/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java?r=1590034#to1010.
There is no namespace check during mangling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3522:
-

I think the methods of the ResourceChangeListener should not modify the state 
directly but wait a cycle - like we do with new/updated resources.

> NPE on startup in ChangeStateTask.getSortKey
> 
>
> Key: SLING-3522
> URL: https://issues.apache.org/jira/browse/SLING-3522
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.5.0
>Reporter: Philipp Marx
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.5.2
>
>
> ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
> whereas getResource() might return null.
> I tracked this down on my system to be a concurrency issue where the 
> ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
> update event. Since the state is now INSTALLED getResource() will return null 
> since it is checking for resource in state UNINSTALL oder INSTALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-3522:


Fix Version/s: Installer Core 3.5.2

> NPE on startup in ChangeStateTask.getSortKey
> 
>
> Key: SLING-3522
> URL: https://issues.apache.org/jira/browse/SLING-3522
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.5.0
>Reporter: Philipp Marx
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.5.2
>
>
> ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
> whereas getResource() might return null.
> I tracked this down on my system to be a concurrency issue where the 
> ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
> update event. Since the state is now INSTALLED getResource() will return null 
> since it is checking for resource in state UNINSTALL oder INSTALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-3522:


Affects Version/s: (was: Installer Configuration Factory 1.0.10)
   Installer Core 3.5.0

> NPE on startup in ChangeStateTask.getSortKey
> 
>
> Key: SLING-3522
> URL: https://issues.apache.org/jira/browse/SLING-3522
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.5.0
>Reporter: Philipp Marx
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.5.2
>
>
> ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
> whereas getResource() might return null.
> I tracked this down on my system to be a concurrency issue where the 
> ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
> update event. Since the state is now INSTALLED getResource() will return null 
> since it is checking for resource in state UNINSTALL oder INSTALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-3522:
---

Assignee: Carsten Ziegeler

> NPE on startup in ChangeStateTask.getSortKey
> 
>
> Key: SLING-3522
> URL: https://issues.apache.org/jira/browse/SLING-3522
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Configuration Factory 1.0.10
>Reporter: Philipp Marx
>Assignee: Carsten Ziegeler
>
> ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
> whereas getResource() might return null.
> I tracked this down on my system to be a concurrency issue where the 
> ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
> update event. Since the state is now INSTALLED getResource() will return null 
> since it is checking for resource in state UNINSTALL oder INSTALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3522) NPE on startup in ChangeStateTask.getSortKey

[Philipp Marx (JIRA)]

Philipp Marx created SLING-3522:
---

 Summary: NPE on startup in ChangeStateTask.getSortKey
 Key: SLING-3522
 URL: https://issues.apache.org/jira/browse/SLING-3522
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Configuration Factory 1.0.10
Reporter: Philipp Marx


ChangeStateTask.getSortKey will internally call getResource().getEntityId(), 
whereas getResource() might return null.

I tracked this down on my system to be a concurrency issue where the 
ResourceState of the task is being updated from UNINSTALL to INSTALLED by an 
update event. Since the state is now INSTALLED getResource() will return null 
since it is checking for resource in state UNINSTALL oder INSTALL.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)

[Antonio Sanso (JIRA)]

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

Antonio Sanso reassigned SLING-3505:


Assignee: Antonio Sanso

> Improve handling of updates to mapping (alias, vanity path)
> ---
>
> Key: SLING-3505
> URL: https://issues.apache.org/jira/browse/SLING-3505
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Carsten Ziegeler
>Assignee: Antonio Sanso
>
> The update handling for the mapping including aliases and vanity path is a 
> simple algorithm which simply updates the whole mapping. Especially with 
> large mapping info spread across the repository, a simple update of a single 
> property results in the whole mapping info to be recreated.
> It would be great if this could be improved.
> Right now, only the active mapping is hold in memory - as a change of a 
> single property might cause to activate a totally different mapping than the 
> one which was changed (e.h. when the ordering is changed), the update needs 
> to be more complex or more information needs to be hold in memory.
> In addition there is more to consider, like if the vanity path info is 
> changed, only the new value is available - but the old is gone.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3428) vanity paths might be shadowed by url mappings

[Antonio Sanso (JIRA)]

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

Antonio Sanso resolved SLING-3428.
--

   Resolution: Fixed
Fix Version/s: Resource Resolver 1.1.2

fixed in rev. 1590592

> vanity paths might be shadowed by url mappings
> --
>
> Key: SLING-3428
> URL: https://issues.apache.org/jira/browse/SLING-3428
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
> Fix For: Resource Resolver 1.1.2
>
>
> As described from [~fmeschbe] some time ago in [0] vanity paths might be 
> shadowed by url mappings in some situations.
> [~fmeschbe] also proposed a patch in [0].
> [0] http://markmail.org/message/7jfx54grwft7joxo



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3428) vanity paths might be shadowed by url mappings

[Antonio Sanso (JIRA)]

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

Antonio Sanso reassigned SLING-3428:


Assignee: Antonio Sanso

> vanity paths might be shadowed by url mappings
> --
>
> Key: SLING-3428
> URL: https://issues.apache.org/jira/browse/SLING-3428
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.1.2
>
>
> As described from [~fmeschbe] some time ago in [0] vanity paths might be 
> shadowed by url mappings in some situations.
> [~fmeschbe] also proposed a patch in [0].
> [0] http://markmail.org/message/7jfx54grwft7joxo



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3428) vanity paths might be shadowed by url mappings

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3428:
--

added test in rev. 1590589

> vanity paths might be shadowed by url mappings
> --
>
> Key: SLING-3428
> URL: https://issues.apache.org/jira/browse/SLING-3428
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>
> As described from [~fmeschbe] some time ago in [0] vanity paths might be 
> shadowed by url mappings in some situations.
> [~fmeschbe] also proposed a patch in [0].
> [0] http://markmail.org/message/7jfx54grwft7joxo



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3521) Merged resource is not available if parent folder is unreadable

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-3521:
---

 Summary: Merged resource is not available if parent folder is 
unreadable
 Key: SLING-3521
 URL: https://issues.apache.org/jira/browse/SLING-3521
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Resource Merger 1.1.2
Reporter: Carsten Ziegeler
 Fix For: Resource Merger 1.1.4


If the parent folder is not readable the hide detection simply skips the 
resource. This seems not very intuitiv, so I think we should rather treat an 
unreadable parent folder in the same way as a readable parent folder without a 
hide property.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling discovery.impl 1.0.8

[Stefan Egli]

Hi,

We'd need one more binding vote here.

Thanks,
Stefan

On 4/22/14 12:19 PM, "Stefan Egli"  wrote:

>Hi,
>
>We solved 1 issue in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12326702
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1050/
>
>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 1050 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Stefan

[jira] [Resolved] (SLING-2917) parent node descriptor (ROOT) gets installed twice

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-2917.
-

Resolution: Fixed

> parent node descriptor (ROOT) gets installed twice
> --
>
> Key: SLING-2917
> URL: https://issues.apache.org/jira/browse/SLING-2917
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.1.8
>
> Attachments: SLING-2917.patch
>
>
> check of processedEntries fails due to not calling #toString() on URLs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-2917) parent node descriptor (ROOT) gets installed twice

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-2917:


Fix Version/s: JCR ContentLoader 2.1.8

> parent node descriptor (ROOT) gets installed twice
> --
>
> Key: SLING-2917
> URL: https://issues.apache.org/jira/browse/SLING-2917
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.1.8
>
> Attachments: SLING-2917.patch
>
>
> check of processedEntries fails due to not calling #toString() on URLs



--
This message was sent by Atlassian JIRA
(v6.2#6252)