[jira] [Updated] (SLING-10902) Add the ability to autogenerate a unique user/group principalName from a hint
[
https://issues.apache.org/jira/browse/SLING-10902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Norman updated SLING-10902:
Description:
This is to support a use case where the user login form utilizes a field other
than the principalName (i.e. email address or phone number) for authentication.
For that use case, the exact principalName value isn't as important and a
unique value can be auto-generated from some other hint. With a generated
unique princpalName, the end user doesn't have to keep retrying to find a value
that hasn't been used already.
With this change the principalName value would be determined by the locating
the first request parameter that is a match of one of the choices in the
following order:
1. *":name"* - value is the exact name to use
{code:java}
curl -F:name=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html
{code}
2. *":name@ValueFrom"* - value is the name of another submitted parameter whose
value is the exact name to use
{code:java}
curl -F:name@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
3. *":nameHint"* - value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
4. *":nameHint@ValueFrom"* - value is the name of another submitted parameter
whose value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
5. otherwise, try the value of any server-side configured
*"principalNameHints"* parameters to treat as a hint that is filtered, trimmed
and made unique
{code:java}
curl -FdisplayName=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
One other benefit of having an extensible way of autogenerating the
principalName values is that one could provide an implementation that generates
randomized principalName values. This should make it more difficult to script
the enumeration of the valid usenames.
was:
This is to support a use case where the user login form utilizes a field other
than the principalName (i.e. email address or phone number) for authentication.
For that use case, the exact principalName value isn't as important and a
unique value can be auto-generated from some other hint. With an generated
unique princpalName, the end user doesn't have to keep retrying to find a value
that hasn't been used already.
With this change the principalName value would be determined by the locating
the first request parameter that is a match of one of the choices in the
following order:
1. *":name"* - value is the exact name to use
{code:java}
curl -F:name=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html
{code}
2. *":name@ValueFrom"* - value is the name of another submitted parameter whose
value is the exact name to use
{code:java}
curl -F:name@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
3. *":nameHint"* - value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
4. *":nameHint@ValueFrom"* - value is the name of another submitted parameter
whose value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
5. otherwise, try the value of any server-side configured
*"principalNameHints"* parameters to treat as a hint that is filtered, trimmed
and made unique
{code:java}
curl -FdisplayName=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
One other benefit of having an extensible way of autogenerating the
principalName values is that one could provide an implementation that generates
randomized principalName values. This should make it more difficult to script
the enumeration of the valid usenames.
> Add the ability to autogenerate a unique user/group principalName from a hint
> -
>
> Key: SLING-10902
> URL: https://issues.apache.org/jira/browse/SLING-10902
> Project: Sling
> Issue Type: New Feature
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: JCR Jackrabbit User Manager 2.2.16
>
>
> This is to
[jira] [Updated] (SLING-10902) Add the ability to autogenerate a unique user/group principalName from a hint
[
https://issues.apache.org/jira/browse/SLING-10902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Norman updated SLING-10902:
Description:
This is to support a use case where the user login form utilizes a field other
than the principalName (i.e. email address or phone number) for authentication.
For that use case, the exact principalName value isn't as important and a
unique value can be auto-generated from some other hint. With a generated
unique princpalName, the end user doesn't have to keep retrying to find a value
that hasn't been used already.
With this change the principalName value would be determined by the locating
the first request parameter that is a match of one of the choices in the
following order:
1. *":name"* - value is the exact name to use
{code:java}
curl -F:name=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html
{code}
2. *":name@ValueFrom"* - value is the name of another submitted parameter whose
value is the exact name to use
{code:java}
curl -F:name@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
3. *":nameHint"* - value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
4. *":nameHint@ValueFrom"* - value is the name of another submitted parameter
whose value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
5. otherwise, try the value of any server-side configured
*"principalNameHints"* parameters to treat as a hint that is filtered, trimmed
and made unique
{code:java}
curl -FdisplayName=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
One other benefit of having an extensible way of autogenerating the
principalName values is that one could provide an implementation that generates
randomized principalName values. This should make it more difficult to script
the enumeration of the valid user names.
was:
This is to support a use case where the user login form utilizes a field other
than the principalName (i.e. email address or phone number) for authentication.
For that use case, the exact principalName value isn't as important and a
unique value can be auto-generated from some other hint. With a generated
unique princpalName, the end user doesn't have to keep retrying to find a value
that hasn't been used already.
With this change the principalName value would be determined by the locating
the first request parameter that is a match of one of the choices in the
following order:
1. *":name"* - value is the exact name to use
{code:java}
curl -F:name=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html
{code}
2. *":name@ValueFrom"* - value is the name of another submitted parameter whose
value is the exact name to use
{code:java}
curl -F:name@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
3. *":nameHint"* - value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
4. *":nameHint@ValueFrom"* - value is the name of another submitted parameter
whose value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
5. otherwise, try the value of any server-side configured
*"principalNameHints"* parameters to treat as a hint that is filtered, trimmed
and made unique
{code:java}
curl -FdisplayName=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
One other benefit of having an extensible way of autogenerating the
principalName values is that one could provide an implementation that generates
randomized principalName values. This should make it more difficult to script
the enumeration of the valid usenames.
> Add the ability to autogenerate a unique user/group principalName from a hint
> -
>
> Key: SLING-10902
> URL: https://issues.apache.org/jira/browse/SLING-10902
> Project: Sling
> Issue Type: New Feature
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: JCR Jackrabbit User Manager 2.2.16
>
>
> This is to
[GitHub] [sling-org-apache-sling-servlets-resolver] enapps-enorman commented on pull request #21: SLING-10889 Make the Servlets Resolver compatible with API 2.24.0
enapps-enorman commented on pull request #21: URL: https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/21#issuecomment-958188498 FYI: the tests on ci will fail until https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/51 is integrated and available. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-servlets-resolver] enapps-enorman opened a new pull request #21: SLING-10889 Make the Servlets Resolver compatible with API 2.24.0
enapps-enorman opened a new pull request #21: URL: https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/21 fix unresolved bundles during integration tests -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SLING-10889) Make the Servlets Resolver compatible with API 2.24.0
[
https://issues.apache.org/jira/browse/SLING-10889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437611#comment-17437611
]
Eric Norman commented on SLING-10889:
-
[~radu] The integration tests were still failing due to unresolved dependencies.
I created PR #21 for your consideration at:
https://github.com/apache/sling-org-apache-sling-servlets-resolver/pull/21
> Make the Servlets Resolver compatible with API 2.24.0
> -
>
> Key: SLING-10889
> URL: https://issues.apache.org/jira/browse/SLING-10889
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Servlets Resolver 2.8.4
>
>
> SLING-8742 increased the API version for {{o.a.s.api.request}} to 2.5.0.
> Since the {{o.a.s.servlets.resolver}} bundle implements some of the
> interfaces from that package, the module has to be recompiled so that it can
> work with version 2.24.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-10902) Add the ability to autogenerate a unique user/group principalName from a hint
Eric Norman created SLING-10902:
---
Summary: Add the ability to autogenerate a unique user/group
principalName from a hint
Key: SLING-10902
URL: https://issues.apache.org/jira/browse/SLING-10902
Project: Sling
Issue Type: New Feature
Reporter: Eric Norman
Assignee: Eric Norman
Fix For: JCR Jackrabbit User Manager 2.2.16
This is to support a use case where the user login form utilizes a field other
than the principalName (i.e. email address or phone number) for authentication.
For that use case, the exact principalName value isn't as important and a
unique value can be auto-generated from some other hint. With an generated
unique princpalName, the end user doesn't have to keep retrying to find a value
that hasn't been used already.
With this change the principalName value would be determined by the locating
the first request parameter that is a match of one of the choices in the
following order:
1. *":name"* - value is the exact name to use
{code:java}
curl -F:name=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html
{code}
2. *":name@ValueFrom"* - value is the name of another submitted parameter whose
value is the exact name to use
{code:java}
curl -F:name@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
3. *":nameHint"* - value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
4. *":nameHint@ValueFrom"* - value is the name of another submitted parameter
whose value is filtered, trimmed and made unique
{code:java}
curl -F:nameHint@ValueFrom=displayName -FdisplayName=myuser -Fpwd=password
-FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
5. otherwise, try the value of any server-side configured
*"principalNameHints"* parameters to treat as a hint that is filtered, trimmed
and made unique
{code:java}
curl -FdisplayName=myuser -Fpwd=password -FpwdConfirm=password
http://localhost:8080/system/userManager/user.create.html{code}
One other benefit of having an extensible way of autogenerating the
principalName values is that one could provide an implementation that generates
randomized principalName values. This should make it more difficult to script
the enumeration of the valid usenames.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-i18n] joerghoh merged pull request #7: SLING-10884 add exclusion for the i18n ResourceBundleProvider
joerghoh merged pull request #7: URL: https://github.com/apache/sling-org-apache-sling-i18n/pull/7 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SLING-5741) discarding complete ResourceBundleCache in case of JSON dictionary
[ https://issues.apache.org/jira/browse/SLING-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437318#comment-17437318 ] Konrad Windszus commented on SLING-5741: The linked PR was never merged, it was closed because it was against the old SVN mirror. Someone would need to come up with a new version, therefore this ticket needs to stay open. > discarding complete ResourceBundleCache in case of JSON dictionary > -- > > Key: SLING-5741 > URL: https://issues.apache.org/jira/browse/SLING-5741 > Project: Sling > Issue Type: Bug > Components: Extensions, i18n >Affects Versions: i18n 2.4.6 >Reporter: Ankit Agarwal >Priority: Major > > In case user is using JSON dictionary then condition mentioned here > https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L198 > will becomes true for any change in languagerootpaths which are cached. And > this will discard complete resource bundle cache. which is different if user > is using sling:Message dictionary. > for example user has json dictionary at path > "/libs/test/i18n/de.json" > and also resource bundle for language "de" is cached so , > "libs/test/i18n/de.json" will be in languageRootPaths. > So any change at "/libs/test/i18n/de.json" will discard complete > resourcebundleCache. > Where as in case of sling:dictionary > languageRootPath will be like "/libs/test/i18n/de" > and any change in this dictionary will have path like this > "/libs/test/i18n/de/testMessage" so condition becomes false and complete > resourcebundleCache. will not be discarded. > Can we improve this, like if condition becomes true, than check among the > cached resourceBundle to which resourceBundle this path belongs to and than > discarding that resourceBundle. and if this resourceBundle is parent of any > ResourceBundle then discard that too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437282#comment-17437282 ] Carsten Ziegeler commented on SLING-10899: -- The resource resolver does not know anything about the adaptions - if we want to improve we probably would need to change the resource resolver to keep track of all resources it handed out and ensure that it returns the same resource object. That alone is already a heavy change which can lead to problems. Now, once we have the same resource object, we need to deliver the same Modifiable(ValueMap) on adaption. We could of course solve the second one without the first one by just keeping track in jcr resource. But then a refresh is still not catched - again with keeping track of everything we might be able to handle it. Then comes the problem of the deep value maps acting across resources, this is where we most likely will loose And then there is so much code doing modifications directly via the JCR API (sometimes mixed with resource API usage), and thats where we have to give up. Or in other words, I don't think that we can easily improve this area without creating new problems - and that is most likely the reason why the code is how it is today. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437268#comment-17437268 ] Henry Kuijpers edited comment on SLING-10899 at 11/2/21, 10:33 AM: --- [~cziegeler], I see. However, the performance impact is quite drastic. Not only in our very specific situation, but also in the Sling product itself: With every filter, with every servlet, with every OSGi service, ... accessing the valuemap of the Resource, a new one is created and therefore, fetching properties from it will always reach out to the repository for the first time, since the cache will always be empty in that case. ValueMap objects are not shared in general, not because technically it's impossible to do so (if you have the reference, you can just use it), but rather because the various APIs etc get a Resource-object to work with (and therefore you will always have to call getValueMap (or adaptTo) to obtain it). I think the impact on performance with this improvement will be quite noticeable. Maybe the ResourceResolver code can be updated, so that it can track resources that have been adapted to a ModifiableValueMap? So that, on commit, it can invalidate the internal caches? was (Author: henry kuijpers): [~cziegeler], I see. However, the performance impact is quite drastic. Not only in our very specific situation, but also in the Sling product itself: With every filter, with every servlet, with every OSGi service, ... accessing the valuemap of the Resource, a new one is created and therefore, fetching properties from it will always reach out to the repository. ValueMap objects are not shared in general, not because technically it's impossible to do so (if you have the reference, you can just use it), but rather because the various APIs etc get a Resource-object to work with (and therefore you will always have to call getValueMap (or adaptTo) to obtain it). I think the impact on performance with this improvement will be quite noticeable. Maybe the ResourceResolver code can be updated, so that it can track resources that have been adapted to a ModifiableValueMap? So that, on commit, it can invalidate the internal caches? > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437268#comment-17437268 ] Henry Kuijpers commented on SLING-10899: [~cziegeler], I see. However, the performance impact is quite drastic. Not only in our very specific situation, but also in the Sling product itself: With every filter, with every servlet, with every OSGi service, ... accessing the valuemap of the Resource, a new one is created and therefore, fetching properties from it will always reach out to the repository. ValueMap objects are not shared in general, not because technically it's impossible to do so (if you have the reference, you can just use it), but rather because the various APIs etc get a Resource-object to work with (and therefore you will always have to call getValueMap (or adaptTo) to obtain it). I think the impact on performance with this improvement will be quite noticeable. Maybe the ResourceResolver code can be updated, so that it can track resources that have been adapted to a ModifiableValueMap? So that, on commit, it can invalidate the internal caches? > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437202#comment-17437202 ] Carsten Ziegeler commented on SLING-10899: -- We don't do anything special for commit/refresh today. The problem exists regardless whether we cache the value map or not. Granted, with caching the value map, the problem might occur more often. But it can already occur today. So we have a couple of problems: there might be stale value maps - but we also support deep tree access/modifications through (modifiable) value maps - which allows for cross resource changes. I'm wondering now if it is really worth caching the value map as it seems to create more problems than it actually solves? In theory we could return the same object for value map and modifiable value map and just make it immutable for value map. This way changes to the modifiable map would be visibile to the read-only value map. But I'Ve also seen code which actually alters a value map and expects that the changes do not end up persisted. So we would break that (rather strange) use case. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437195#comment-17437195 ] Joerg Hoh commented on SLING-10899: --- I am not sure if it's possible to know when the underlying ResourceResolver has performed a commit/refresh and clear the cached ValueMap in that case (if we can handle it on the JCR side, it would be fine as well). > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[
https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437160#comment-17437160
]
Carsten Ziegeler commented on SLING-10899:
--
I think we had a lot of discussions around this in the past - if my memory
serves me well, we lazily agreed that an adaption of an object to another
object should return the same instance - if possible. That's why we added the
caching in SlingAdaptable. Of course there are edge cases like adapting to an
InputStream where caching doesn't make sense.
So looking at it from this POV, the current behaviour (returning a new
ValueMap) seems to be a bug - and returning the same ValueMap is more
consistent. For read-only cases this should not matter anyway but improves
performance.
For write cases, it gets more tricky - I'm not 100% sure there - although
having a consistent view of the changed content looks like the way to go, so
again returning the same object seems to be the right thing.
But there is a higher level problem which will not be solved by this - and in
the past we lazily agreed in the past to not solve it: two Resource objects
representing the same resource will result different ValueMap objects - and
therefore (in the write case) potentially different state, like:
{noformat}
Resource a = resolver.getResource("/foo");
ValueMap va = a.adaptTo(ValueMap.class);
Resource b = resolver.getResource("/foo");
ValueMap vb = b.adaptTo(ValueMap.class);
{noformat}
in that case va != vb (same for the modifiable value map)
> Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
> --
>
> Key: SLING-10899
> URL: https://issues.apache.org/jira/browse/SLING-10899
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 3.0.22
>Reporter: Henry Kuijpers
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: JCR Resource 3.0.24
>
>
> I was performance testing our application. There is a specific part of the
> code where we have a set of ~500 resources and we sort them based on a few
> properties of the resources. Multiple properties are used (which results in
> multiple calls to getValueMap). The sorting is done using a comparator, so
> the logic that determines the order is accessed numerous times.
> We've seen quite a decrease in performance when doing this with Resources
> that are of type JcrNodeResource. Turns out that the result of getValueMap
> (or adaptTo((Value)Map.class)) is not cached.
> As you can see in the adaptTo()-method implementation:
> https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136
> this call bypasses the AdapterFactory framework and also bypasses any
> caching that happens over there.
> What's even more unfortunate, is that JcrValueMap is implementing caching via
> https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49
> . That caching is not leveraged properly, because every call to getValueMap
> returns a new JcrValueMap, instead of reusing a previously created one.
> One change that can be done is maybe converting the logic inside the
> adaptTo()-method to a dedicated AdapterFactory implementation, so that
> caching is done by default?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437156#comment-17437156 ] Henry Kuijpers commented on SLING-10899: One issue I was thinking of is using a modifiablevaluemap or similar, adjusting a few properties, then trying to read those properties again using a previously obtained Resource's ValueMap. In the code before this change, it would return the new and changed properties, because it always made a new ValueMap, now, it doesn't do that anymore. Would that be an issue? Or was the fact that this happened previously, actually a bug? > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437145#comment-17437145 ] Carsten Ziegeler commented on SLING-10899: -- I think it is easier to cache directly in the JcrNodeResource to avoid further indirections. I've applied such a change in https://github.com/apache/sling-org-apache-sling-jcr-resource/commit/7c09c1e99cba3e5545af05028e88aa518f3272d9 > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10899: - Fix Version/s: JCR Resource 3.0.24 > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-10899: Assignee: Carsten Ziegeler > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Assignee: Carsten Ziegeler >Priority: Major > Fix For: JCR Resource 3.0.24 > > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10899: - Component/s: (was: ResourceResolver) (was: API) JCR > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-10899: - Affects Version/s: (was: Resource Resolver 1.7.10) (was: API 2.23.6) JCR Resource 3.0.22 > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: API, ResourceResolver >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling i18n 2.5.18
+1 Carsten Am 01.11.2021 um 19:17 schrieb Jörg Hoh: Hi, We solved 1 issue in this release:https://issues.apache.org/jira/projects/SLING/versions/12349990 Staging repository:https://repository.apache.org/content/repositories/orgapachesling-2545/ You can use this UNIX script to download the release and verify the signatures:https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2545 /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. Jörg -- Carsten Ziegeler Adobe cziege...@apache.org
