[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[
https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098273#comment-17098273
]
Tomoko Uchida commented on LUCENE-9321:
---
{quote}I don't like it to publish HTML pages on lucene.apache.org with absolute
links to lucene.apache.org. We recently changed to HTTPS, so for similar cases
all links in historic Javadocs would need to be rewritten. Thanks to redirects
it still works, but there can be man-in-the-middle problems.
{quote}
I could miss some point, but as for redirecting "renderJavadoc" task emits
"https:" link so there should be no http access, and hence no http => https
redirecting; though I have no idea there are other reasons to prefer relative
paths over absolute urls from security perspective (attackers can take
advantage valunabilities of ssl/tsl when we use absolute urls instead of
relative paths?).
[https://github.com/apache/lucene-solr/blob/master/gradle/render-javadoc.gradle#L64]
(I have confirmed it generates "https://~~"; links.)
> Port documentation task to gradle
> -
>
> Key: LUCENE-9321
> URL: https://issues.apache.org/jira/browse/LUCENE-9321
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: general/build
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: screenshot-1.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is a placeholder issue for porting ant "documentation" task to gradle.
> The generated documents should be able to be published on lucene.apache.org
> web site on "as-is" basis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7822) IllegalArgumentException thrown instead of a CorruptIndexException
[
https://issues.apache.org/jira/browse/LUCENE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098298#comment-17098298
]
Adrien Grand commented on LUCENE-7822:
--
I'd like to revive this issue since I agree with Martin that the
CorruptIndexException is much more useful, the true problem is that the file is
corrupt, not that the version bits are illegal or that a given codec doesn't
exist? In the case of systems like Solr or Elasticsearch, knowing that the
problem is a corruption is also more useful as in some cases you can re-create
the shard from another copy that isn't corrupt automatically.
Would it be acceptable to change checkFooter to throw the CorruptIndexException
with the prior exception as a suppressed exception when checksums don't match?
Or maybe we should stop using the variant of checkFooter that takes a prior
exception and call checksumEntireFile up-front instead on our metadata files as
suggested above?
> IllegalArgumentException thrown instead of a CorruptIndexException
> --
>
> Key: LUCENE-7822
> URL: https://issues.apache.org/jira/browse/LUCENE-7822
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.5.1
>Reporter: Martin Amirault
>Priority: Minor
> Attachments: LUCENE-7822.patch
>
>
> Similarly to LUCENE-7592 , When an {{*.si}} file is corrupted on very
> specific part an IllegalArgumentException is thrown instead of a
> CorruptIndexException.
> StackTrace (Lucene 6.5.1):
> {code}
> java.lang.IllegalArgumentException: Illegal minor version: 12517381
> at
> __randomizedtesting.SeedInfo.seed([1FEB5987CFA44BE:B8755B5574F9F3BF]:0)
> at org.apache.lucene.util.Version.(Version.java:385)
> at org.apache.lucene.util.Version.(Version.java:371)
> at org.apache.lucene.util.Version.fromBits(Version.java:353)
> at
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:97)
> at
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
> at
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
> at
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
> at
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> Simple fix would be to add IllegalArgumentException to the catch list at
> {{org/apache/lucene/index/SegmentInfos.java:289}}
> Other variations for the stacktraces:
> {code}
> java.lang.IllegalArgumentException: invalid codec filename '_�.cfs', must
> match: _[a-z0-9]+(_.*)?\..*
> at
> __randomizedtesting.SeedInfo.seed([8B3FDE317B8D634A:A8EE07E5EB4B0B13]:0)
> at
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:270)
> at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:252)
> at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:246)
> at
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:248)
> at
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
> at
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
> at
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
> at
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> {code}
> java.lang.IllegalArgumentException: An SPI class of type
> org.apache.lucene.codecs.Codec with name 'LucenI62' does not exist. You need
> to add the corresponding JAR file supporting this SPI to your classpath. The
> current classpath supports the following names: [Lucene62, Lucene50,
> Lucene53, Lucene54, Lucene60]
> at
> __randomizedtesting.SeedInfo.seed([925DE160F7260F99:B026EB9373CB6368]:0)
> at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:116)
> at org.apache.lucene.codecs.Codec.forName(Codec.java:116)
> at org.apache.lucene.index.SegmentInfos.readCodec(SegmentInfos.java:424)
> at
> org.apache.lucene.index.Se
[GitHub] [lucene-solr] samuelgmartinez opened a new pull request #1480: SOLR-14456: Fix Content-Type header forwarding on compressed requests
samuelgmartinez opened a new pull request #1480: URL: https://github.com/apache/lucene-solr/pull/1480 # Description `HttpSolrCall` and `HttpSolrClient` were using `Content-Encoding` header incorrectly, as they were setting the charset as the encoding for the request. This bug surfaces only when a Solr node is forwarding a request to another node and tries to forward the original headers. # Solution Adjusted the behaviour to set the charset encoding as part of the `Content-Type` (as is specified by the HTTP standard) and `Content-Encoding` is now properly forwarded when available. # Tests Run the Solr test suites successfully but only from IntelliJ as from the terminal was failing everywhere (from lucene tests to some other random failures, even with badapples set to false). Regardin new/modified unit tests, none. Since the `HttpSolrCall` has no tests and this takes a really complicated setup to test it, I just wanted to verify that the introduced changes won't break existing suites. Of course I'm open to add them but I'd appreciate some direction on how to build such a test. # Checklist Please review the following and check all that apply: - [ x ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ x ] I have created a Jira issue and added the issue ID to my pull request title. - [ x ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ x ] I have developed this patch against the `master` branch. - [ x ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9087) Should the BKD tree use a fixed maxPointsInLeafNode?
[ https://issues.apache.org/jira/browse/LUCENE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera resolved LUCENE-9087. -- Fix Version/s: 8.6 Assignee: Ignacio Vera Resolution: Fixed > Should the BKD tree use a fixed maxPointsInLeafNode? > - > > Key: LUCENE-9087 > URL: https://issues.apache.org/jira/browse/LUCENE-9087 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: 8.6 > > Attachments: Study of BKD tree performance with different values for > max points per leaf.pdf > > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently the BKD tree uses a fixed maxPointsInLeafNode provided in the > constructor. For the current default codec the value is set to 1024. This is > a good compromise between memory usage and performance of the BKD tree. > Lowering this value can increase search performance but it has a penalty in > memory usage. Now that the BKD tree can be load off-heap, this can be less of > a concern. Note that lowering too much that value can hurt performance as > well as the tree becomes too deep and benefits are gone. > For data types that use the tree as an effective R-tree (ranges and shapes > datatypes) the benefits are larger as it can minimise the overlap between > leaf nodes. > Finally, creating too many leaf nodes can be dangerous at write time as > memory usage depends on the number of leaf nodes created. The writer creates > a long array of length = numberOfLeafNodes. > What I am wondering here is if we can improve this situation in order to > create the most efficient tree? My current ideas are: > > * We can adapt the points per leaf depending on that number so we create a > tree with the best depth and best points per leaf. Note that for the for 1D > case we have an upper estimation of the number of points that the tree will > be indexing. > * Add a mechanism so field types can easily define their best points per > leaf. In the case, field types like ranges or shapes can define its own value > to minimise overlap. > * Maybe the default is just too high now that we can load the tree off-heap. > Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098363#comment-17098363 ] Uwe Schindler commented on LUCENE-9321: --- I was talking about historic javadocs with absolute links that need to be fixed. I would like to prevent that by just having relative links. This is also important for the targz bundle. It should be self contained and not have absolute links. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098368#comment-17098368 ] Uwe Schindler commented on LUCENE-9321: --- bq. I wouldn't require a second (independent) build pass. If it's something required for the "release" then let's have a release task in gradle and take care of it there (javadocs built twice but within the same run of the build - the "release" build). Otherwise the "release" scripts are duplicating what could as well be done within the main build script? During the release you build maven artifacts (with absolute links) going to local module folder. In addition you build global javadocs with relative links. Both can be done with a same set of tasks, just dynamically duplicate then in the bud module. When doing this change 2 things: the output die and apply URI.relativize(). The global documentation task depends on those variants, the jar file builds for maven depend on standard javadocs task, that delegates to renderJavaDoc with absolute links. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098369#comment-17098369 ] Uwe Schindler commented on LUCENE-9321: --- By the way I explained that very detailed in my proposal. Please read! > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida reassigned LUCENE-9321: - Assignee: (was: Tomoko Uchida) > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9321: -- Comment: was deleted (was: By the way I explained that very detailed in my proposal. Please read!) > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098368#comment-17098368 ] Uwe Schindler edited comment on LUCENE-9321 at 5/3/20, 11:32 AM: - bq. I wouldn't require a second (independent) build pass. If it's something required for the "release" then let's have a release task in gradle and take care of it there (javadocs built twice but within the same run of the build - the "release" build). Otherwise the "release" scripts are duplicating what could as well be done within the main build script? During the release you build maven artifacts (with absolute links) going to local module folder. In addition you build global javadocs with relative links. So I agree, this should be done in the same build run. IMHO, both can be done with a same set of tasks, we just need to dynamically duplicate them in our build plugin. When doing this, I'd change 2 things: the output directory and apply URI.relativize() to our clones. The global documentation task depends on those variants; the jar file builds for maven and those running during normal "developer interaction" depend on standard javadocs task, that delegates to renderJavaDoc with absolute links. I have a plan how to do this, let me get started and propose a pull request. When all is done, the full blown javadocs are never created for developers, only if the release manager, smoketester, or jenkins calls "gradle documentation" or "gradle release" (or whatever). If you just run tests or run precommit, only the "minimal checks" are done. In addition the documentation is not built, only local javadocs for the module. I will also try to fix the hardcoded URLs and make then properties, so Jenkins can tell where the documentation will land. This also alows downstream users to publish javadocs on their own pages (we have several clones). was (Author: thetaphi): bq. I wouldn't require a second (independent) build pass. If it's something required for the "release" then let's have a release task in gradle and take care of it there (javadocs built twice but within the same run of the build - the "release" build). Otherwise the "release" scripts are duplicating what could as well be done within the main build script? During the release you build maven artifacts (with absolute links) going to local module folder. In addition you build global javadocs with relative links. Both can be done with a same set of tasks, just dynamically duplicate then in the bud module. When doing this change 2 things: the output die and apply URI.relativize(). The global documentation task depends on those variants, the jar file builds for maven depend on standard javadocs task, that delegates to renderJavaDoc with absolute links. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098363#comment-17098363 ] Uwe Schindler edited comment on LUCENE-9321 at 5/3/20, 11:34 AM: - I was talking about historic javadocs with absolute links that need to be fixed. I would like to prevent that in the future by just having relative links. It also allows 3rd parties to republish our javadocs on serveral web pages. With absolute links those would need to rewrite all of them. This is also important for the targz bundle. It should be self contained and not have absolute links: If somebody is browsing the documentation folder in the targz bundle, heshe should no see absolute links. was (Author: thetaphi): I was talking about historic javadocs with absolute links that need to be fixed. I would like to prevent that by just having relative links. This is also important for the targz bundle. It should be self contained and not have absolute links. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-9321: - Assignee: Uwe Schindler > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9321: -- Fix Version/s: master (9.0) > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098384#comment-17098384 ] Uwe Schindler commented on LUCENE-9321: --- [~tomoko]: You have unassigned, I will take this issue. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098385#comment-17098385 ] Tomoko Uchida commented on LUCENE-9321: --- bq. I would like to prevent that by just having relative links. This is also important for the targz bundle. There's one thing I'm not fully understand. According to this policy, how do we handle links in Solr javadocs to Lucene javadocs. To be strictly consistent, those should be relative links for website, but absolute links for tar.gz (because Lucene and Solr archives are separately distributed). ? > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098363#comment-17098363 ] Uwe Schindler edited comment on LUCENE-9321 at 5/3/20, 11:37 AM: - I was talking about historic javadocs with absolute links that need to be fixed. I would like to prevent that in the future by just having relative links. It also allows 3rd parties to republish our javadocs on serveral 3rd party web pages. With absolute links those would need to rewrite all of them. This is also important for the targz bundle. It should be self contained and not have absolute links: If somebody is browsing the documentation folder in the targz bundle, heshe should no see absolute links. was (Author: thetaphi): I was talking about historic javadocs with absolute links that need to be fixed. I would like to prevent that in the future by just having relative links. It also allows 3rd parties to republish our javadocs on serveral web pages. With absolute links those would need to rewrite all of them. This is also important for the targz bundle. It should be self contained and not have absolute links: If somebody is browsing the documentation folder in the targz bundle, heshe should no see absolute links. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098388#comment-17098388 ] Uwe Schindler commented on LUCENE-9321: --- The Solr bundle does not have the Lucene javadocs, so they need to be absolute, but only for that case. This is - I agree with Dawid - something that onbly affects the final documentation "ant/gradle documentation" build, which is done by release manager and jenkins only. In that case it would produce 2 different sets of javadocs (as explained before). > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098390#comment-17098390 ] Uwe Schindler commented on LUCENE-9321: --- IMHO: I agree with Dawid, Solr Javadocs should not have links over to Lucene. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14419) Query DLS {"param":"ref"}
[
https://issues.apache.org/jira/browse/SOLR-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098392#comment-17098392
]
Mikhail Khludnev commented on SOLR-14419:
-
Colleagues, are there any opinions?
> Query DLS {"param":"ref"}
> -
>
> Key: SOLR-14419
> URL: https://issues.apache.org/jira/browse/SOLR-14419
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14419.patch, SOLR-14419.patch, SOLR-14419.patch
>
>
> What we can do with plain params:
> {{q=\{!parent which=$prnts}...&prnts=type:parent}}
> obviously I want to have something like this in Query DSL:
> {code}
> { "query": { "parents":{ "which":{"param":"prnts"}, "query":"..."}}
> "params": {
> "prnts":"type:parent"
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9357) AssertingSorted(Set|Numeric)DocValues should be unwrappable
Mikhail Khludnev created LUCENE-9357:
Summary: AssertingSorted(Set|Numeric)DocValues should be
unwrappable
Key: LUCENE-9357
URL: https://issues.apache.org/jira/browse/LUCENE-9357
Project: Lucene - Core
Issue Type: Sub-task
Components: modules/test-framework
Reporter: Mikhail Khludnev
# Obviously singular docValues might mimic multivalued ones via
{{DocValues.singleton()}}. However, some algorithms prefers to
{{DocValues.unwrap()}} them if possible.
# AssertingDocValues blocks this unwrapping slightly changing codepath for
singular DVs.
h3. AS IS
{{AssertingDV -> Singleton -> SingularDV}}
h3. TODO
{{Singleton -> AssertingDV -> SingularDV}}
I think it's trivial, worthwhile and 0% risk. Are there any concerns?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098401#comment-17098401 ] Tomoko Uchida commented on LUCENE-9321: --- (It's merely my personal preference, but I really do not like deleting comments from an issue tracker even if they are trivial ones, please ...) > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7871) false positive match BlockJoinSelector[SortedDV] when child value is absent
[
https://issues.apache.org/jira/browse/LUCENE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098430#comment-17098430
]
Mikhail Khludnev commented on LUCENE-7871:
--
[~jpountz] Sorry for flashing it back after two years. I've stumbled upon this
code while tinkering LUCENE-9328. Isn't it's worth for {{ToParentDocValues}} to
implement {{DocValuesIterator}} since it already has {{advanceExact()}} but it
via calling {{advance()}} on underneath DV-iter?
> false positive match BlockJoinSelector[SortedDV] when child value is absent
>
>
> Key: LUCENE-7871
> URL: https://issues.apache.org/jira/browse/LUCENE-7871
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 7.0, 8.0
>
> Attachments: LUCENE-7871.patch, LUCENE-7871.patch, LUCENE-7871.patch,
> LUCENE-7871.patch, LUCENE-7871.patch
>
>
> * fix false positive match for SortedSetDV
> * make {{children}} an iterator instead of bitset.
> see [the
> comment|https://issues.apache.org/jira/browse/LUCENE-7407?focusedCommentId=16042640&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16042640]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[
https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098447#comment-17098447
]
Tomoko Uchida commented on LUCENE-9201:
---
To organize issues and avoid confusion, I would like to close this issue for
now.
In terms of creating an equivalent of Ant's "documentaion-lint",
{{checkBrokenLinks}} is still missing, but I feel like it's better to be
handled by LUCENE-9321 or its sub-task.
In any case, "documentaion-lint" has been decomposed into three independent
tasks they have very different purposes - unused import check ("ecjLint":
Done), missing documentation check ("checkMissingDocs": Done), and broken links
check for packaging/publishing ("checkBrokenLinks": Missing). So to me at this
time there's no meaning "porting 'documentation-lint' to gradle").
Please feel free to reopen if it's needed.
> Port documentation-lint task to Gradle build
>
>
> Key: LUCENE-9201
> URL: https://issues.apache.org/jira/browse/LUCENE-9201
> Project: Lucene - Core
> Issue Type: Sub-task
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch,
> LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png,
> javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png,
> task_deps3.png
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Ant build's "documentation-lint" target consists of those two sub targets.
> * "-ecj-javadoc-lint" (Javadoc linting by ECJ)
> * "-documentation-lint"(Missing javadocs / broken links check by python
> scripts)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida resolved LUCENE-9201. --- Fix Version/s: master (9.0) Resolution: Fixed > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking
[ https://issues.apache.org/jira/browse/SOLR-14351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098451#comment-17098451 ] ASF subversion and git services commented on SOLR-14351: Commit e7c7a62a84927cf6c49d75229f9ebfbe2feb9df9 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e7c7a62 ] SOLR-14351: Oops; add back null check for ZkController > Harden MDCLoggingContext.clear depth tracking > - > > Key: SOLR-14351 > URL: https://issues.apache.org/jira/browse/SOLR-14351 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Time Spent: 1h > Remaining Estimate: 0h > > MDCLoggingContext tracks recursive calls and only clears when the recursion > level is back down to 0. If a caller forgets to register and ends up calling > clear any ways, then this can mess things up. Additionally I found at least > one place this is occurring, which led me to investigate this matter. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking
[ https://issues.apache.org/jira/browse/SOLR-14351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098453#comment-17098453 ] ASF subversion and git services commented on SOLR-14351: Commit 6c9024f77358ae1f372b3078691ada3f64a84e59 in lucene-solr's branch refs/heads/branch_8x from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c9024f ] SOLR-14351: Oops; add back null check for ZkController (cherry picked from commit e7c7a62a84927cf6c49d75229f9ebfbe2feb9df9) > Harden MDCLoggingContext.clear depth tracking > - > > Key: SOLR-14351 > URL: https://issues.apache.org/jira/browse/SOLR-14351 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Time Spent: 1h > Remaining Estimate: 0h > > MDCLoggingContext tracks recursive calls and only clears when the recursion > level is back down to 0. If a caller forgets to register and ends up calling > clear any ways, then this can mess things up. Additionally I found at least > one place this is occurring, which led me to investigate this matter. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9328) SortingGroupHead to reuse DocValues
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9328: - Attachment: LUCENE-9328.patch Status: Patch Available (was: Patch Available) > SortingGroupHead to reuse DocValues > --- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch > > Time Spent: 50m > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9328) SortingGroupHead to reuse DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098555#comment-17098555
]
Mikhail Khludnev commented on LUCENE-9328:
--
It's better than I expected.
* Asserting DVs and sigletonDVs, spawned subtask.
* Need to migrate {{ToParentDocValues}} to {{advanceExact()}} will spawn one.
* there's a runtime check in one class, I commented it and will discuss it
separately.
* curiously, it's hard to put a test which covering grouping over blockjoin in
a proper module, so far it's landed in solr/test.
> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/grouping
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> That's why
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #341: SOLR-12131: ExternalRoleRuleBasedAuthorizationPlugin
janhoy commented on a change in pull request #341:
URL: https://github.com/apache/lucene-solr/pull/341#discussion_r418962495
##
File path:
solr/core/src/test/org/apache/solr/security/BaseTestRuleBasedAuthorizationPlugin.java
##
@@ -43,47 +45,61 @@
import org.apache.solr.request.SolrRequestHandler;
import org.apache.solr.security.AuthorizationContext.CollectionRequest;
import org.apache.solr.security.AuthorizationContext.RequestType;
-import org.apache.solr.common.util.CommandOperation;
import org.hamcrest.core.IsInstanceOf;
import org.hamcrest.core.IsNot;
import org.junit.Test;
import static java.util.Collections.emptyMap;
import static java.util.Collections.singletonList;
import static java.util.Collections.singletonMap;
+import static org.apache.solr.common.util.CommandOperation.captureErrors;
import static org.apache.solr.common.util.Utils.getObjectByPath;
import static org.apache.solr.common.util.Utils.makeMap;
-import static org.apache.solr.common.util.CommandOperation.captureErrors;
-
-public class TestRuleBasedAuthorizationPlugin extends SolrTestCaseJ4 {
- private static final int STATUS_OK = 200;
- private static final int FORBIDDEN = 403;
- private static final int PROMPT_FOR_CREDENTIALS = 401;
-
- String permissions = "{" +
- " user-role : {" +
- "steve: [dev,user]," +
- "tim: [dev,admin]," +
- "joe: [user]," +
- "noble:[dev,user]" +
- " }," +
- " permissions : [" +
- "{name:'schema-edit'," +
- " role:admin}," +
- "{name:'collection-admin-read'," +
- "role:null}," +
- "{name:collection-admin-edit ," +
- "role:admin}," +
- "{name:mycoll_update," +
- " collection:mycoll," +
- " path:'/update/*'," +
- " role:[dev,admin]" +
- "}," +
- "{name:read , role:dev }," +
- "{name:freeforall, path:'/foo', role:'*'}]}";
+/**
+ * Base class for testing RBAC. This will test the {@link
RuleBasedAuthorizationPlugin} implementation
+ * but also serves as a base class for testing other sub classes
+ */
+@SuppressWarnings("unchecked")
+public class BaseTestRuleBasedAuthorizationPlugin extends SolrTestCaseJ4 {
Review comment:
This test baseclass is not refactored 100%, as it tests the json
user-role mapping while the test subclass overrides stuff to tests the external
roles...
##
File path: solr/solr-ref-guide/src/securing-solr.adoc
##
@@ -53,6 +53,7 @@ Authorization makes sure that only users with the necessary
roles/permissions ca
// tag::list-of-authorization-plugins[]
*
<>
+*
<>
Review comment:
Did not find a better sub header to link to
##
File path:
solr/core/src/test/org/apache/solr/security/BaseTestRuleBasedAuthorizationPlugin.java
##
@@ -440,13 +431,29 @@ public void
testAllPermissionDeniesActionsWhenUserIsNotCorrectRole() {
"collectionRequests", "go",
"handler", handler,
"params", new MapSolrParams(emptyMap()))
-, FORBIDDEN, (Map) Utils.fromJSONString( "{" +
-"user-role:{" +
-" dev:[dev_role]," +
-" admin:[admin_role]}," +
-"permissions:[" +
-" {name:all, role:'admin_role'}" +
-"]}"));
+, FORBIDDEN);
+ }
+
+ void addPermission(String permissionName, String role, String path,
Map params) {
Review comment:
The test class is based on the old test, but I refactored it by adding
the `addPermission`, `removePermission`, `clearUserRoles`, `setUserRole`
methods for use in the test
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12131) Authorization plugin support for getting user's roles from the outside
[
https://issues.apache.org/jira/browse/SOLR-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098574#comment-17098574
]
Jan Høydahl commented on SOLR-12131:
See updated PR
* Brought up to date with master branch
* RefGuide text revised, also addressing [~noble.paul]'s feedback
* New param 'rolesClaim' in JWTAuthPlugin which can pull user roles from any
JWT claim
Please review, targeting 8.6 for this
> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> Project: Solr
> Issue Type: New Feature
> Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping
> users to roles. However, when users are authenticated by an external Identity
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the
> Authorization plugin should be able to accept (verified) roles from the
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization
> plugin can then pull the roles from request. By piggy-backing on the
> Principal, we have a seamless way to transfer extra external information, and
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #341: SOLR-12131: ExternalRoleRuleBasedAuthorizationPlugin
janhoy commented on a change in pull request #341:
URL: https://github.com/apache/lucene-solr/pull/341#discussion_r419163646
##
File path:
solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java
##
@@ -16,329 +16,45 @@
*/
package org.apache.solr.security;
-import java.io.IOException;
import java.lang.invoke.MethodHandles;
import java.security.Principal;
-import java.util.ArrayList;
import java.util.HashMap;
-import java.util.HashSet;
-import java.util.List;
import java.util.Map;
import java.util.Set;
-import java.util.function.Function;
-import org.apache.solr.common.SpecProvider;
-import org.apache.solr.common.util.Utils;
-import org.apache.solr.common.util.ValidatingJsonMap;
-import org.apache.solr.common.util.CommandOperation;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import static java.util.Arrays.asList;
-import static java.util.Collections.unmodifiableMap;
-import static java.util.function.Function.identity;
-import static java.util.stream.Collectors.toMap;
-import static org.apache.solr.handler.admin.SecurityConfHandler.getListValue;
import static org.apache.solr.handler.admin.SecurityConfHandler.getMapValue;
-
-public class RuleBasedAuthorizationPlugin implements AuthorizationPlugin,
ConfigEditablePlugin, SpecProvider {
+/**
+ * Original implementation of Rule Based Authz plugin which configures
user/role
+ * mapping in the security.json configuration
+ */
+public class RuleBasedAuthorizationPlugin extends
RuleBasedAuthorizationPluginBase {
Review comment:
Should this plugin have a new name, e.g.
`ExplicitRolesRuleBasedAuthorizationPlugin`? So far I just kept the name to
stay 100% back compat.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9328) SortingGroupHead to reuse DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098619#comment-17098619
]
Lucene/Solr QA commented on LUCENE-9328:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 8s{color}
| {color:red} LUCENE-9328 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9328 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13001957/LUCENE-9328.patch |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/266/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/grouping
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> That's why
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14454) support for UTF-8 (string) types with DocValuesType.BINARY
[
https://issues.apache.org/jira/browse/SOLR-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098622#comment-17098622
]
David Smiley commented on SOLR-14454:
-
The first two seem promising but I don't think the 3rd (compression) should be
present here. I think it's up to the codec to implement compression. In fact
Lucene 8.5 just got this -- See LUCENE-9211.
> support for UTF-8 (string) types with DocValuesType.BINARY
> --
>
> Key: SOLR-14454
> URL: https://issues.apache.org/jira/browse/SOLR-14454
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal is to add support for string fields with arbitrarily large values in
> the {{/export}} handler and streaming expressions.
> {{StrField}} values are currently limited to 32766 bytes for the case where
> {{indexed=true}} or {{docValues=true}}. Exceeding this value triggers an
> "immense field" warning, and causes indexing to fail for the associated input
> doc.
> Configuring a {{StrField}} field as "{{indexed=false docValues=false}}"
> removes this size limitation, so it is already possible to have large
> _stored_ {{StrField}} values. But the "{{docValues=true}}" prerequisite for
> the {{/export}} handler (and consequently for streaming expressions) limits
> the size of field that can be used in conjunction with these features.
> Adding support for UTF-8/string field types with {{DocValuesType.BINARY}}
> would address this limitation and allow considerable flexibility in the
> implementation of custom field types. N.b.: this would address field value
> retrieval use cases only (e.g., {{/export}} and {{useDocValuesAsStored}});
> neither sorting nor faceting would be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14454) support for UTF-8 (string) types with DocValuesType.BINARY
[
https://issues.apache.org/jira/browse/SOLR-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098625#comment-17098625
]
David Smiley commented on SOLR-14454:
-
Please see SOLR-10255 which I worked on years ago which seems seems to be
duplicative here.
> support for UTF-8 (string) types with DocValuesType.BINARY
> --
>
> Key: SOLR-14454
> URL: https://issues.apache.org/jira/browse/SOLR-14454
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal is to add support for string fields with arbitrarily large values in
> the {{/export}} handler and streaming expressions.
> {{StrField}} values are currently limited to 32766 bytes for the case where
> {{indexed=true}} or {{docValues=true}}. Exceeding this value triggers an
> "immense field" warning, and causes indexing to fail for the associated input
> doc.
> Configuring a {{StrField}} field as "{{indexed=false docValues=false}}"
> removes this size limitation, so it is already possible to have large
> _stored_ {{StrField}} values. But the "{{docValues=true}}" prerequisite for
> the {{/export}} handler (and consequently for streaming expressions) limits
> the size of field that can be used in conjunction with these features.
> Adding support for UTF-8/string field types with {{DocValuesType.BINARY}}
> would address this limitation and allow considerable flexibility in the
> implementation of custom field types. N.b.: this would address field value
> retrieval use cases only (e.g., {{/export}} and {{useDocValuesAsStored}});
> neither sorting nor faceting would be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #1470: SOLR-14354: Async or using threads in better way for HttpShardHandler
CaoManhDat commented on a change in pull request #1470:
URL: https://github.com/apache/lucene-solr/pull/1470#discussion_r419198072
##
File path:
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
##
@@ -259,12 +261,10 @@ private ShardResponse take(boolean bailOnError) {
@Override
public void cancelAll() {
-for (Cancellable cancellable : requests) {
+for (Cancellable cancellable : responseCancellableMap.values()) {
Review comment:
+1
##
File path:
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
##
@@ -54,6 +53,10 @@
import org.apache.solr.util.tracing.GlobalTracer;
import org.apache.solr.util.tracing.SolrRequestCarrier;
+/**
+ * Submit requests in async manner.
+ * This class is not thread-safe so all methods should be called in a same
thread.
Review comment:
+1
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1471: Revised SOLR-14014 PR Against Master
MarcusSorealheis commented on a change in pull request #1471:
URL: https://github.com/apache/lucene-solr/pull/1471#discussion_r419210970
##
File path: solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java
##
@@ -24,29 +31,26 @@
import org.apache.solr.core.CoreContainer;
import org.apache.solr.core.SolrCore;
-import javax.servlet.http.HttpServletRequest;
-import javax.servlet.http.HttpServletResponse;
-
-import java.io.IOException;
-import java.io.InputStream;
-import java.io.OutputStreamWriter;
-import java.io.Writer;
-import java.nio.charset.StandardCharsets;
-
/**
* A simple servlet to load the Solr Admin UI
*
* @since solr 4.0
*/
public final class LoadAdminUiServlet extends BaseSolrServlet {
+ // check system properties for whether or not admin UI is disabled, default
is false
+ private static final boolean disabled =
Boolean.parseBoolean(System.getProperty("disableAdminUI", "false"));
+
@Override
- public void doGet(HttpServletRequest _request,
-HttpServletResponse _response)
- throws IOException {
+ public void doGet(HttpServletRequest _request, HttpServletResponse
_response) throws IOException {
HttpServletRequest request = SolrDispatchFilter.closeShield(_request,
false);
HttpServletResponse response = SolrDispatchFilter.closeShield(_response,
false);
-
+
+if(disabled){
Review comment:
Handling the raw response works better. Looking at the snippet on this
page originally I didn't have the full context. Good suggestion. Thanks 👍
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
