[jira] [Commented] (SLING-5017) Moving a JCR node not reflected in JcrNodeResource
[
https://issues.apache.org/jira/browse/SLING-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14744100#comment-14744100
]
Alexander Klimetschek commented on SLING-5017:
--
I see your points, but the workaround of refetching is extremely ugly in case
of a move of the request resource:
{code}
// request start
// ... do move ...
// due to resouce.getPath cached after moving, use the underlying correct Node
path to fetch it again
Node node = request.getResource().adaptTo(Node.class);
Resource resource = request.getResourceResolver().getResource(node.getPath());
{code}
> Moving a JCR node not reflected in JcrNodeResource
> --
>
> Key: SLING-5017
> URL: https://issues.apache.org/jira/browse/SLING-5017
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Alexander Klimetschek
>
> When moving a JCR node via the JCR API behind a resource, Resource.getPath()
> and Resource.getName() will still return the old path and name:
> {code:java}
> // e.g. "/some/oldname"
> Resource resource = request.getResource();
> // move via JCR API (no move available in resource API)
> Node node = resource.adaptTo(Node.class);
> node.getSession().move(node.getPath(), node.getParent().getPath() +
> "newname");
> node.getSession().save();
> resource.getName(); // returns "oldname"
> resource.getPath(); // returns "/some/oldname"
> {code}
> This is because the path is [cached in
> JcrItemResource|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L83]
> and it uses the getPath() and [getName() implementation of
> AbstractResource|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AbstractResource.java#L53]
> which are based on the cached path.
> To ensure the correct transient JCR semantics, the resource should pass
> getPath() and getName() through to the underlying Node (respectively Item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5017) Moving a JCR node not reflected in JcrNodeResource
[
https://issues.apache.org/jira/browse/SLING-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14742968#comment-14742968
]
Carsten Ziegeler commented on SLING-5017:
-
There are a lot of these situations - moving is one of them, changes to
properties is another etc. In addition there might not be a 1:1 mapping between
the node path and the resource path, resources might be decorated or otherwise
wrapped.
The code doing the modifications (like the move) knows what it's doing, it has
to clearly document this and what clients need to expect. This is the only way
I see to solve the problem. Otherwise we get a solution which is slightly
better but still does not cover all cases; so I think it's far better to not
start going this direction at all.
Caching of some things is in many cases a necessity for performance -
unfortunately that's a fact.
The request keeping the resource which was targetted is a good thing and the
app should know that once someone moves this resource, it's not the same
anymore.
Again, there might be situations where it looks pretty easy to fix, but from
that fix arise at least two situations where this will cause trouble.
> Moving a JCR node not reflected in JcrNodeResource
> --
>
> Key: SLING-5017
> URL: https://issues.apache.org/jira/browse/SLING-5017
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Alexander Klimetschek
>
> When moving a JCR node via the JCR API behind a resource, Resource.getPath()
> and Resource.getName() will still return the old path and name:
> {code:java}
> // e.g. "/some/oldname"
> Resource resource = request.getResource();
> // move via JCR API (no move available in resource API)
> Node node = resource.adaptTo(Node.class);
> node.getSession().move(node.getPath(), node.getParent().getPath() +
> "newname");
> node.getSession().save();
> resource.getName(); // returns "oldname"
> resource.getPath(); // returns "/some/oldname"
> {code}
> This is because the path is [cached in
> JcrItemResource|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L83]
> and it uses the getPath() and [getName() implementation of
> AbstractResource|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AbstractResource.java#L53]
> which are based on the cached path.
> To ensure the correct transient JCR semantics, the resource should pass
> getPath() and getName() through to the underlying Node (respectively Item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5017) Moving a JCR node not reflected in JcrNodeResource
[
https://issues.apache.org/jira/browse/SLING-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14742063#comment-14742063
]
Carsten Ziegeler commented on SLING-5017:
-
I think we shouldn't do this (and I think we have discusses this some years
ago): As soon as you leave the resource api, and modify the underlying data you
will get out of sync for resources fetched before this. This is known and
expected. The solution is simple: a) stay in the resource api and b) if you
don't stay there refetch resources.
> Moving a JCR node not reflected in JcrNodeResource
> --
>
> Key: SLING-5017
> URL: https://issues.apache.org/jira/browse/SLING-5017
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Alexander Klimetschek
>
> When moving a JCR node via the JCR API behind a resource, Resource.getPath()
> and Resource.getName() will still return the old path and name:
> {code:java}
> // e.g. "/some/oldname"
> Resource resource = request.getResource();
> // move via JCR API (no move available in resource API)
> Node node = resource.adaptTo(Node.class);
> node.getSession().move(node.getPath(), node.getParent().getPath() +
> "newname");
> node.getSession().save();
> resource.getName(); // returns "oldname"
> resource.getPath(); // returns "/some/oldname"
> {code}
> This is because the path is [cached in
> JcrItemResource|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L83]
> and it uses the getPath() and [getName() implementation of
> AbstractResource|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AbstractResource.java#L53]
> which are based on the cached path.
> To ensure the correct transient JCR semantics, the resource should pass
> getPath() and getName() through to the underlying Node (respectively Item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5017) Moving a JCR node not reflected in JcrNodeResource
[ https://issues.apache.org/jira/browse/SLING-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14741827#comment-14741827 ] Alexander Klimetschek commented on SLING-5017: -- Two notes: * should check if other methods have the same issue (knowing that the ValueMap caches property values) * using ResourceResolver.commit() (instead of a plain jcr session.save()) does not seem to make a difference, as all it does is call session.save() and there is no invalidation mechanism for existing resource objects (and IMO should not, the JCR implementation already has to cover this tricky part) > Moving a JCR node not reflected in JcrNodeResource > -- > > Key: SLING-5017 > URL: https://issues.apache.org/jira/browse/SLING-5017 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Alexander Klimetschek > > When moving a JCR node via the JCR API behind a resource, after the resource > has been fetched already, e.g. the request resource, Resource.getPath() and > Resource.getName() will still return the old path and name. > This is because the path is [cached in > JcrItemResource|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L83] > and it uses the getPath() and [getName() implementation of > AbstractResource|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AbstractResource.java#L53] > which are based on the cached path. > To ensure the correct transient JCR semantics, the resource should pass > getPath() and getName() through to the underlying Node (respectively Item). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
