[jira] [Commented] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index
[ https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853746#comment-17853746 ] Roy Teeuwen commented on OAK-8046: -- [~thomasm] in a content management system with 100.000nd of pages and assets, doing a query that is below 200 items is not always feasible? There are even ootb features that read more nodes. Plus how would you influence the time a query takes, besides setting a good index definition > Result items are not always correctly counted against the configured read > limit if a query uses a lucene index > --- > > Key: OAK-8046 > URL: https://issues.apache.org/jira/browse/OAK-8046 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.8.7 >Reporter: Georg Henzler >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.12.0, 1.10.1, 1.8.12 > > Attachments: OAK-8046-take2.patch, OAK-8046.patch > > > There are cases where an index is re-opened during query execution. In that > case, already returned entries are read again and skipped, so basically > counted twice. This should be fixed to only count entries once (see also [1]) > The issue most likely exists since the read limit was introduced with OAK-6875 > [1] > https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index
[ https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848198#comment-17848198 ] Roy Teeuwen commented on OAK-8046: -- [~thomasm] Thanks for the prompt reply! Seeing as we have more than 100.000 nodes / pages and we have processes which query for these pages, we are getting this log all the time. So I guess the only thing we can do is move this class to an ignored log file :(? Very weird to get this as LOG.info but we can't act / do anything about it > Result items are not always correctly counted against the configured read > limit if a query uses a lucene index > --- > > Key: OAK-8046 > URL: https://issues.apache.org/jira/browse/OAK-8046 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.8.7 >Reporter: Georg Henzler >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.12.0, 1.10.1, 1.8.12 > > Attachments: OAK-8046-take2.patch, OAK-8046.patch > > > There are cases where an index is re-opened during query execution. In that > case, already returned entries are read again and skipped, so basically > counted twice. This should be fixed to only count entries once (see also [1]) > The issue most likely exists since the read limit was introduced with OAK-6875 > [1] > https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index
[ https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848177#comment-17848177 ] Roy Teeuwen commented on OAK-8046: -- [~thomasm] [~catholicon] we see the "Change in index version detected. Query would be performed without offset" logged 100.00 times per day on certain instances, but for me it's not clear what the action is required to fix this? Can we as consumer of Apache Oak (used in AEM) do anything to mitigate this log line of occurring? Should a reindex be triggered, or something else? > Result items are not always correctly counted against the configured read > limit if a query uses a lucene index > --- > > Key: OAK-8046 > URL: https://issues.apache.org/jira/browse/OAK-8046 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.8.7 >Reporter: Georg Henzler >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.12.0, 1.10.1, 1.8.12 > > Attachments: OAK-8046-take2.patch, OAK-8046.patch > > > There are cases where an index is re-opened during query execution. In that > case, already returned entries are read again and skipped, so basically > counted twice. This should be fixed to only count entries once (see also [1]) > The issue most likely exists since the read limit was introduced with OAK-6875 > [1] > https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765258#comment-17765258
]
Roy Teeuwen commented on OAK-10448:
---
[~kwin] this also causes following downstream issue, where it is not only
Query, but also Authorizable and Group:
[https://github.com/ist-dresden/composum-nodes/issues/310]
For example:
[https://github.com/ist-dresden/composum-nodes/blob/develop/usermgr/src/main/java/com/composum/sling/core/usermanagement/service/GroupFacade.java]
[https://github.com/ist-dresden/composum-nodes/blob/develop/usermgr/src/main/java/com/composum/sling/core/usermanagement/service/ServiceUser.java]
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10222) Provide package dependency on jars / bundles in an OSGi environment
Roy Teeuwen created OAK-10222:
-
Summary: Provide package dependency on jars / bundles in an OSGi
environment
Key: OAK-10222
URL: https://issues.apache.org/jira/browse/OAK-10222
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Roy Teeuwen
We want to be able to state that a package should not install unless a OSGi
bundle is available. There are situations where the package depends on code to
be available before it can be correctly installed.
An example when this is useful is when using an external install hook, which is
not available yet. This could be the case if you have the following content
package:
* {{all (content-package)}}
** {{vendor-framework-all (content-package)}}
*** {{vendor-framework-core (bundle containing hook)}}
** {{application-content (content-package with install hook depending on
vendor-framework-core bundle)}}
An option to be able to fix this in an "easy" approach would for example be by
registering OSGi bundles as packages to the package manager, the bundle
symbolic name and version can be used as package name + version.
Any other suggestions are welcome. I have already tried using an approach from
Sling:
https://sling.apache.org/documentation/bundles/installer-provider-installhook.html.
But this is not possible to use this because you can't put an installPathRegex
from the {{application-content}} content-package on an embedded
{{vendor-framework-core}} package. It also feels like an even bigger hack /
workaround than the proposal
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-8971) Indexing: dynamic boost, as an alternative to IndexFieldProvider
[
https://issues.apache.org/jira/browse/OAK-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470489#comment-17470489
]
Roy Teeuwen commented on OAK-8971:
--
Super, thanks both for the clarifications and help! Sadly enough it seems I
wont be able to test this, I am using oak-core 1.22 (AEM 6.5.11), so only when
we would go to AEMaaCS we will be able to do the migration to use valueRegex
(it's also only then that we will have the issue of IndexFieldProvider being
deprecated so that's ok)
[~thomasm] for reference, the query that took 2 seconds on the custom field in
the lucene index is on a JCR repo where the following query returns 172106
paths:
{code:java}
SELECT [jcr:path] from [nt:base]
WHERE isdescendantnode('/content/my-site/en') {code}
It is indeed very weird that the query takes so long (query tested and time it
takes taken from CRX DE > Tools > Query JCR_SQL2), seeing as it's doing a
native query on a specific index field. If I use the Query Performance tool and
then I get following result, so I guess the time in CRX De is also the
rendering of the actual paths
{noformat}
Indexes Used
lucene(/oak:index/lucene)
Execution Time
Total time: 1126 ms
Query execution time: 0 ms
Get nodes time: 24 ms
Result node count time: 1102 ms
Number of nodes in result: 2165 {noformat}
> Indexing: dynamic boost, as an alternative to IndexFieldProvider
>
>
> Key: OAK-8971
> URL: https://issues.apache.org/jira/browse/OAK-8971
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.30.0
>
> Attachments: OAK-8971.patch
>
>
> The org.apache.jackrabbit.oak.plugins.index.lucene.spi.IndexFieldProvider is
> a callback that allows to change the behavior of indexing. There are multiple
> problems:
> * (1) Not available using oak-run
> * (2) Only available for Lucene indexes
> Instead of a callback, a configuration option in the index property should be
> added, such that the most commonly used features are available in oak-run,
> and can be implemented in other indexes (e.g. Elastisearch, Solr).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OAK-8971) Indexing: dynamic boost, as an alternative to IndexFieldProvider
[
https://issues.apache.org/jira/browse/OAK-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469331#comment-17469331
]
Roy Teeuwen commented on OAK-8971:
--
Just tested it on our DEV environment, and I think indeed that filtering on
client side would be a lot easier, I tried the SQL like query, and that took 22
seconds to execute, without the like it took 6,5 seconds.
If I use my extra indexed field from the IndexFieldProvider it takes 2 seconds,
so that one does still stay the fastest one though! Looking forward to the docs
for the valueRegex to see if we can speed up those 6,5 seconds so that I can
remove the deprecated IndexFieldProvider :)
{code:java}
SELECT [jcr:path] from [nt:base]
WHERE native('lucene','inlinevariable:(company)')
AND isdescendantnode('/content/my-site/en'){code}
> Indexing: dynamic boost, as an alternative to IndexFieldProvider
>
>
> Key: OAK-8971
> URL: https://issues.apache.org/jira/browse/OAK-8971
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.30.0
>
> Attachments: OAK-8971.patch
>
>
> The org.apache.jackrabbit.oak.plugins.index.lucene.spi.IndexFieldProvider is
> a callback that allows to change the behavior of indexing. There are multiple
> problems:
> * (1) Not available using oak-run
> * (2) Only available for Lucene indexes
> Instead of a callback, a configuration option in the index property should be
> added, such that the most commonly used features are available in oak-run,
> and can be implemented in other indexes (e.g. Elastisearch, Solr).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OAK-8971) Indexing: dynamic boost, as an alternative to IndexFieldProvider
[ https://issues.apache.org/jira/browse/OAK-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469202#comment-17469202 ] Roy Teeuwen commented on OAK-8971: -- [~thomasm] what I mean with stripped out is that the character isn't even in the lucene index, on index time it is already stripped out. Am I mistaken in this? How would I write your query so that it searches on all properties for the like syntax, the following doesnt seem to work: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/my-site/en]) and contains(s.*, 'company') and s.* like '\%\%company\%\%' > Indexing: dynamic boost, as an alternative to IndexFieldProvider > > > Key: OAK-8971 > URL: https://issues.apache.org/jira/browse/OAK-8971 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.30.0 > > Attachments: OAK-8971.patch > > > The org.apache.jackrabbit.oak.plugins.index.lucene.spi.IndexFieldProvider is > a callback that allows to change the behavior of indexing. There are multiple > problems: > * (1) Not available using oak-run > * (2) Only available for Lucene indexes > Instead of a callback, a configuration option in the index property should be > added, such that the most commonly used features are available in oak-run, > and can be implemented in other indexes (e.g. Elastisearch, Solr). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OAK-8971) Indexing: dynamic boost, as an alternative to IndexFieldProvider
[ https://issues.apache.org/jira/browse/OAK-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469163#comment-17469163 ] Roy Teeuwen commented on OAK-8971: -- [~thomasm] well the %% are stripped out by default by the analyser of lucene, so thats why we cant search that way. So if you would look into the index, it would not be visible at all. Would the valueRegex solve this? And how can you use it? > Indexing: dynamic boost, as an alternative to IndexFieldProvider > > > Key: OAK-8971 > URL: https://issues.apache.org/jira/browse/OAK-8971 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.30.0 > > Attachments: OAK-8971.patch > > > The org.apache.jackrabbit.oak.plugins.index.lucene.spi.IndexFieldProvider is > a callback that allows to change the behavior of indexing. There are multiple > problems: > * (1) Not available using oak-run > * (2) Only available for Lucene indexes > Instead of a callback, a configuration option in the index property should be > added, such that the most commonly used features are available in oak-run, > and can be implemented in other indexes (e.g. Elastisearch, Solr). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OAK-8971) Indexing: dynamic boost, as an alternative to IndexFieldProvider
[ https://issues.apache.org/jira/browse/OAK-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467175#comment-17467175 ] Roy Teeuwen commented on OAK-8971: -- [~thomasm] I see that the IndexFieldProvider is deprecated. The use case that you implemented with the dynamicBoost is totally not the use case we use it for though. We have for example the following text saved in a property "Hello, welcome to %%company%%". In the IndexFieldProvider we will scrape every property and if there is a property that is delimited with %%, we will save that as a separate lucene property. That way we can do a native query where we say, give every node that has "%%company%%" in it (or other words than company of course). Is there an alternative to IndexFieldProvider to do this? The %% delimiters get stripped out by the analyzers in the default lucene index so we can't search for %%company%%, and also the default lucene index is even deprecated nowadays to use > Indexing: dynamic boost, as an alternative to IndexFieldProvider > > > Key: OAK-8971 > URL: https://issues.apache.org/jira/browse/OAK-8971 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.30.0 > > Attachments: OAK-8971.patch > > > The org.apache.jackrabbit.oak.plugins.index.lucene.spi.IndexFieldProvider is > a callback that allows to change the behavior of indexing. There are multiple > problems: > * (1) Not available using oak-run > * (2) Only available for Lucene indexes > Instead of a callback, a configuration option in the index property should be > added, such that the most commonly used features are available in oak-run, > and can be implemented in other indexes (e.g. Elastisearch, Solr). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OAK-9132) Feature toggles
[ https://issues.apache.org/jira/browse/OAK-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152537#comment-17152537 ] Roy Teeuwen commented on OAK-9132: -- [~mreutegg] why is this implemented on oak and not on Felix level? Or Sling is Felix is too low level. There is no real direct link with Oak > Feature toggles > --- > > Key: OAK-9132 > URL: https://issues.apache.org/jira/browse/OAK-9132 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core-spi >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Introduce the concept of [feature > toggles|https://martinfowler.com/articles/feature-toggles.html]. Oak already > has various system properties that control configuration or runtime behaviour > of the repository. With Oak moving to a more frequent release cycle there is > an increased need for control over new features. Some features should not be > enabled by default, for other features we may want to have a way to disable > if they introduce unexpected side effects for some users. Preferably, feature > toggles can be changed at runtime and no restart is required. > It should also be possible to integrate third party systems that manage > feature toggles centrally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-5073) Bug in JcrPathParser
[
https://issues.apache.org/jira/browse/OAK-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640694#comment-15640694
]
Roy Teeuwen commented on OAK-5073:
--
Wow, that was fast :)! Thanks Michael. I was debugging it but couldn't
immediately see where it went wrong else I would have tried to fix it myself.
Should have checked out oak so I could have run the integration tests
> Bug in JcrPathParser
>
>
> Key: OAK-5073
> URL: https://issues.apache.org/jira/browse/OAK-5073
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Roy Teeuwen
>Assignee: Michael Dürig
> Fix For: 1.5.13
>
> Attachments: OAK_5073.patch
>
>
> I seem to have found a bug in the
> org.apache.jackrabbit.oak.namepath.JcrPathParser, when looking up following
> property through the session, it returns me false, while the property does
> exist.
> I have debugged the code and found following results.
> A file.scss exists at /etc/shared/mixins/file.scss
> The api that I am using:
>
> session.propertyExists("/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data");
> returns false
> => PathListener elements
> ["","etc","mixins","shared","file.scss","jcr:content","jcr:data"]
>
>
> session.propertyExists("/etc/shared/mixins/something/../file.scss/jcr:content/jcr:data");
> returns true
> => PathListener elements
> ["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
>
> session.propertyExists("/etc/shared/mixins/file.scss/jcr:content/jcr:data");
> returns true
> => PathListener elements
> ["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
> So it seems that when using the same word shared to go back on a second time
> after other words in between, results in an error:
> /etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data
> I tried this with other examples
> (/etc/anything/mixins/anything/../file.scss/jcr:content/jcr:data) and always
> came to the same result that the api is not working correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5073) Bug in JcrPathParser
Roy Teeuwen created OAK-5073:
Summary: Bug in JcrPathParser
Key: OAK-5073
URL: https://issues.apache.org/jira/browse/OAK-5073
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Roy Teeuwen
I seem to have found a bug in the
org.apache.jackrabbit.oak.namepath.JcrPathParser, when looking up following
property through the session, it returns me false, while the property does
exist.
I have debugged the code and found following results.
A file.scss exists at /etc/shared/mixins/file.scss
The api that I am using:
session.propertyExists("/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data");
returns false => PathListener elements
["","etc","mixins","shared","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/something/../file.scss/jcr:content/jcr:data");
returns true => PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/file.scss/jcr:content/jcr:data");
returns true => PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
So it seems that when using the same word shared to go back on a second time
after other words in between, results in an error:
/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data
I tried this with other examples
(/etc/anything/mixins/anything/../file.scss/jcr:content/jcr:data) and always
came to the same result that the api is not working correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5073) Bug in JcrPathParser
[
https://issues.apache.org/jira/browse/OAK-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roy Teeuwen updated OAK-5073:
-
Description:
I seem to have found a bug in the
org.apache.jackrabbit.oak.namepath.JcrPathParser, when looking up following
property through the session, it returns me false, while the property does
exist.
I have debugged the code and found following results.
A file.scss exists at /etc/shared/mixins/file.scss
The api that I am using:
session.propertyExists("/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data");
returns false
=> PathListener elements
["","etc","mixins","shared","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/something/../file.scss/jcr:content/jcr:data");
returns true
=> PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/file.scss/jcr:content/jcr:data");
returns true
=> PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
So it seems that when using the same word shared to go back on a second time
after other words in between, results in an error:
/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data
I tried this with other examples
(/etc/anything/mixins/anything/../file.scss/jcr:content/jcr:data) and always
came to the same result that the api is not working correctly.
was:
I seem to have found a bug in the
org.apache.jackrabbit.oak.namepath.JcrPathParser, when looking up following
property through the session, it returns me false, while the property does
exist.
I have debugged the code and found following results.
A file.scss exists at /etc/shared/mixins/file.scss
The api that I am using:
session.propertyExists("/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data");
returns false => PathListener elements
["","etc","mixins","shared","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/something/../file.scss/jcr:content/jcr:data");
returns true => PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
session.propertyExists("/etc/shared/mixins/file.scss/jcr:content/jcr:data");
returns true => PathListener elements
["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
So it seems that when using the same word shared to go back on a second time
after other words in between, results in an error:
/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data
I tried this with other examples
(/etc/anything/mixins/anything/../file.scss/jcr:content/jcr:data) and always
came to the same result that the api is not working correctly.
> Bug in JcrPathParser
>
>
> Key: OAK-5073
> URL: https://issues.apache.org/jira/browse/OAK-5073
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Roy Teeuwen
>
> I seem to have found a bug in the
> org.apache.jackrabbit.oak.namepath.JcrPathParser, when looking up following
> property through the session, it returns me false, while the property does
> exist.
> I have debugged the code and found following results.
> A file.scss exists at /etc/shared/mixins/file.scss
> The api that I am using:
>
> session.propertyExists("/etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data");
> returns false
> => PathListener elements
> ["","etc","mixins","shared","file.scss","jcr:content","jcr:data"]
>
>
> session.propertyExists("/etc/shared/mixins/something/../file.scss/jcr:content/jcr:data");
> returns true
> => PathListener elements
> ["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
>
> session.propertyExists("/etc/shared/mixins/file.scss/jcr:content/jcr:data");
> returns true
> => PathListener elements
> ["","etc","shared","mixins","file.scss","jcr:content","jcr:data"]
> So it seems that when using the same word shared to go back on a second time
> after other words in between, results in an error:
> /etc/shared/mixins/shared/../file.scss/jcr:content/jcr:data
> I tried this with other examples
> (/etc/anything/mixins/anything/../file.scss/jcr:content/jcr:data) and always
> came to the same result that the api is not working correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
