[jira] [Assigned] (JCR-4455) condition index-rule handling more broken after JCR-4339
[
https://issues.apache.org/jira/browse/JCR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Köll reassigned JCR-4455:
---
Assignee: Claus Köll
> condition index-rule handling more broken after JCR-4339
>
>
> Key: JCR-4455
> URL: https://issues.apache.org/jira/browse/JCR-4455
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Ate Douma
>Assignee: Claus Köll
>Priority: Major
> Attachments: exposing-JCR-4455.patch
>
>
> [~c_koell]
> When reviewing the fix applied for JCR-4339 before going through an upgrade
> to 2.18.2, I noticed that, while it fixes the reported problem, it does so
> only in simple ('happy path') scenarios. Now it is broken when trying to use
> multiple index-rule definitions for one node type.
> The logic for finding the applicable indexing rule for a specific property no
> longer considers (checks) if the there is a condition for that property.
> Instead, that check is postponed/moved to the method *calling*
> #getApplicableIndexingRule.
> But this is incorrect because now the #getApplicableIndexingRule method
> returns the first *type* matching rule, regardless of the *property* it
> should be applicable for.
> For example, it is perfectly feasible, and sometimes even needed, to have
> multiple index-rules for the same node type, like the following enhanced
> version of test resource indexing_config6.xml, which can be used to verify
> the logic now is broken:
> {code:xml}
>
> other
>
>
> foo
> {code}
> The important points to expose the new bug is:
> * the index-rule for property other is defined *before* the index-rule for
> property foo
> * (for this example) the index-rule for property other doesn't have a
> condition
> With the above, the property foo will *not* be indexed, regardless its value,
> because the first 'matching' rule returned from #getApplicableIndexingRule
> for a node of type nt:unstructured will be the rule for property other. But
> will always return false on the (now postponed/delegated) call to
> rule.isIndexed(propertyName: foo), because *that* rule doesn't has a
> propertyConfig for foo (only for other).
> I'll attach a patch (based on trunk) to demonstrate the above failing using
> the new IndexingConfigurationImplTest#testMatchCondition test.
> Note that the current #testMatchCondition() test itself also is broken: it
> actually *does not* test the intended condition, but tests for it to *not*
> match using assertFalse instead of assertTrue.
> Which indeed is needed to pass the test because the indexing_config6.xml
> configuration file itself contains an invalid (incomplete) index-rule.
> Instead of the current content:
> {code:xml}
>
> {code}
> it actually should be:
> {code:xml}
>
> foo
> {code}
> to pass the test with assertTrue.
> I'll also fix that test method in my patch, which then however will fail,
> because of the above reported problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[ANNOUNCE] Apache Jackrabbit Oak 1.8.14 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit Oak. The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release: Release Notes -- Apache Jackrabbit Oak -- Version 1.8.14 Introduction Jackrabbit Oak is a scalable, high-performance hierarchical content repository designed for use as the foundation of modern world-class web sites and other demanding content applications. Jackrabbit Oak 1.8.14 is a patch release that contains fixes and improvements over Oak 1.8. Jackrabbit Oak 1.8.x releases are considered stable and targeted for production use. The Oak effort is a part of the Apache Jackrabbit project. Apache Jackrabbit is a project of the Apache Software Foundation. Changes in Oak 1.8.14 - Technical task [OAK-6812] - UpdateOp Condition: be consistent about the support for non-revision properties [OAK-7896] - RDB*Store: update mysql driver reference to 8.0.13 [OAK-7970] - RDB*Store: add profile for DB2 11.1 JDBC driver [OAK-7971] - RDB*Store: update DB2 JDBC reference to 4.19.77 [OAK-8002] - RDBDocumentStore: add RDB-specific MissingLastRevSeeker [OAK-8074] - RDB*Store: update mysql-connector-java dependency to 8.0.15 [OAK-8080] - RDB*Store: move DB-specific config hints from Javadoc into oak-doc [OAK-8083] - RDB*Store: add SQLServer specific documentation [OAK-8087] - RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8 [OAK-8147] - RDBBlobStore: add perf logging for JDBC read operations [OAK-8307] - RDBDocumentStore: add DEBUG logging when fetching index metadata fails [OAK-8311] - RDBDocumentStore: allow to turn off RDB-specific MissingLastRevSeeker [OAK-8332] - update Tomcat JDBC dependency to 8.5.41 [OAK-8337] - RDBDocumentStore: refactor index dumping code [OAK-8338] - RDBDocumentStoreJDBC: fix theoretically possible NPE in perflogging code [OAK-8346] - RDBDocumentStore*: fix several potential but improbable NPEs [OAK-8349] - RDBDocumentStore*: "reset clusterId tool" in oak-run [OAK-8368] - RDBDocumentNodeStoreBuilder: refactor setRDBConnection for consistency [OAK-8371] - Stop using deprecated DocumentMK.Builder in RDB tests [OAK-8378] - rdb/oak-run: update usage and documentation for garbage command Bug [OAK-7155] - Executor in S3DataStoreFactory is not shut down [OAK-7378] - Continuous Revision GC counts _deletedOnce with every run [OAK-7543] - MissingLastRevSeekerTest fails on MongoDB with secondary preferred [OAK-7564] - Commit fails when forced journal push throws exception [OAK-7886] - Re-registering node type may corrupt registry [OAK-7956] - Conflict may leave behind _collisions entry [OAK-8024] - oak-http generates invalid html [OAK-8207] - Read-only DocumentNodeStore tries to create root document [OAK-8271] - Lucene path transformed result doesn't accomodate wildcards in relative path [OAK-8437] - direct children, exact, and parent path restrictions don't work when path transformation takes place Improvement [OAK-7213] - Avoid call for child node when bundle contains all children [OAK-7310] - Empty package-info.java causes unnecessary rebuild [OAK-8135] - HTTP service may not select correct media type if multiple are specified in Accept header field [OAK-8310] - Potentially misleading conflict exception message Test [OAK-8353] - Additional test for OAK-8012 Task [OAK-7220] - add benchmark focused on string write performance [OAK-7787] - oak-it: NoClassDefFoundError in log with Java 11 [OAK-7842] - solr: suppress problematic commons-fileupload dependency [OAK-8163] - examples: update Tomcat dependency to 7.0.93 [OAK-8179] - Update jacoco to 0.8.3 [OAK-8180] - Update mockito to 2.25.1 [OAK-8196] - Update httpclient/mime dependencies to 4.5.8 [OAK-8208] - oak-run/rdb: add --rdbtableprefix option [OAK-8235] - Upgrade Solr to version 6.6.6 [OAK-8286] - Update jetbrains nullability annotations to 17.0.0 [OAK-8290] - Update org.apache.felix.framework for jdk13 [OAK-8312] - MissingLastRevSeeker and NodeDocumentSweeper: improve progress logging [OAK-8331] - Update Tika dependency to 1.21 [OAK-8334] - Update Jackson dependency to 2.9.9 [OAK-8341] - Include tomcat-jdbc/juli in oak-run [OAK-8348] - Update surefire/failsafe dependencies to 2.22.2 [OAK-8350] - Update animal-sniffer dependency to 1.18 [OAK-8376] - update commons-codec dependency to 1.12 [OAK-8414] - Update jar-plugin dependency to 3.1.2 In addition to the above-mentioned changes, this release contains all changes included up to the Apache Jackrabbit Oak 1.8.x release. For more detailed information about all the changes in this and other Oak releases,
UNSUBSCRIBE
Em qua, 3 de jul de 2019 às 17:14, Woonsan Ko (JIRA)
escreveu:
> Woonsan Ko created JCR-4458:
> ---
>
> Summary: When JcrRemotingServlet deployed on non-root
> context, AclResource Webdav request fails
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.18.2
> Reporter: Woonsan Ko
>
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured as a servlet on servletPath, "/server", in a web application,
> the contextPath of which is "/cms" for example, then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, from a JCR Session from the repository like the
> following:
>
> {code}
> String repositoryAddress = (args.length != 0) ? args[0] : "
> http://localhost:8080/cms/server";;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
>
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
>
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath property.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
--
att.
Marcelo Taborda Vicente
Cel: 55 (41) 9545-5084
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878542#comment-16878542
]
Woonsan Ko commented on JCR-4458:
-
Indeed. Seems like the same issue! :-)
Thanks a lot for your attention! I couldn’t figure out an easy solution
yesterday as JcrPrivilegeReport doesn’t have a direct access to servletContext.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server";;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JCR-4456) EOL Jackrabbit 2.10
[ https://issues.apache.org/jira/browse/JCR-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-4456. - Resolution: Fixed > EOL Jackrabbit 2.10 > --- > > Key: JCR-4456 > URL: https://issues.apache.org/jira/browse/JCR-4456 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Users of 2.10 who can move to Java 8 should switch to the latest stable > release of 2.18. > Users of 2.10 who can move to Java 7 should switch to the latest stable > release of 2.14. > Users of 2.10 who still are on Java 6 can switch to the latest release of > 2.12. > What it'll mean in actual actions: > - links will be removed from the download page > - news will be posted on the homepage > - [announce] will be sent to jr-user, jr-dev, oak-dev > - branch and tags WILL stay there -- This message was sent by Atlassian JIRA (v7.6.3#76005)
