[jira] [Commented] (LUCENE-9355) missing releases from testbackwardscompatibility
[
https://issues.apache.org/jira/browse/LUCENE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097799#comment-17097799
]
Noble Paul commented on LUCENE-9355:
How do you see this error? [~janhoy] any inputs on what's probably missing?
> missing releases from testbackwardscompatibility
>
>
> Key: LUCENE-9355
> URL: https://issues.apache.org/jira/browse/LUCENE-9355
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Mike Drob
>Priority: Major
>
> I'm not sure what needs to be added for the 7.7.3 release, but can you take a
> look at it [~noble] or figure out who to ask for help?
> {noformat}
>[smoker] confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker] 7.7.3
>[smoker] Traceback (most recent call last):
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1487, in
>[smoker] main()
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1413, in main
>[smoker] downloadOnly=c.download_only)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1465, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
> version, gitRevision, version, testArgs, baseURL)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 566, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath,
> gitRevision, version, testArgs, tmpDir, baseURL)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 752, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1388, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by
> TestBackwardsCompatibility?
> {noformat}
--
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] mocobeta commented on pull request #1477: LUCENE-9321: Port markdown task to Gradle
mocobeta commented on pull request #1477: URL: https://github.com/apache/lucene-solr/pull/1477#issuecomment-622650749 I am not sure if it's worth here, "render-javadoc.gradle" has a utility method to convert project path into output doc folder path: https://github.com/apache/lucene-solr/blob/master/gradle/render-javadoc.gradle#L21 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] mocobeta commented on pull request #1477: LUCENE-9321: Port markdown task to Gradle
mocobeta commented on pull request #1477: URL: https://github.com/apache/lucene-solr/pull/1477#issuecomment-622650279 I was not aware of that this task depends on projects' relative paths. To me, before proceeding it we need to manage to reach a consensus about the destination (output) directory for "renderJavadoc" anyway...? 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] [Updated] (LUCENE-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-9354: Fix Version/s: trunk > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Assignee: Robert Muir >Priority: Minor > Labels: ready-to-commit > Fix For: trunk > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-9354. - Resolution: Fixed Thanks [~philippe@camellia] for submitting these improvements to snowball and getting them into lucene! > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Assignee: Robert Muir >Priority: Minor > Labels: ready-to-commit > Fix For: trunk > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned LUCENE-9354: --- Assignee: Robert Muir > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Assignee: Robert Muir >Priority: Minor > Labels: ready-to-commit > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097770#comment-17097770 ] ASF subversion and git services commented on LUCENE-9354: - Commit 7a849f6943e5c7fdeb77883410b28d3e19a1c175 in lucene-solr's branch refs/heads/master from Philippe Ouellet [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7a849f6 ] LUCENE-9354: Sync French stop words with latest version from Snowball. (#1474) * Sync French stop words with latest version from Snowball. This new version removed some French homonyms from the list * Use latest master commit from snowball-website * LUCENE-9354: regenerate with 'gradle snowball * LUCENE-9354: add CHANGES.txt entry > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Priority: Minor > Labels: ready-to-commit > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097771#comment-17097771 ] ASF subversion and git services commented on LUCENE-9354: - Commit 7a849f6943e5c7fdeb77883410b28d3e19a1c175 in lucene-solr's branch refs/heads/master from Philippe Ouellet [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7a849f6 ] LUCENE-9354: Sync French stop words with latest version from Snowball. (#1474) * Sync French stop words with latest version from Snowball. This new version removed some French homonyms from the list * Use latest master commit from snowball-website * LUCENE-9354: regenerate with 'gradle snowball * LUCENE-9354: add CHANGES.txt entry > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Priority: Minor > Labels: ready-to-commit > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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-9354) Refresh French stop words to remove homonyms
[ https://issues.apache.org/jira/browse/LUCENE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097772#comment-17097772 ] ASF subversion and git services commented on LUCENE-9354: - Commit 7a849f6943e5c7fdeb77883410b28d3e19a1c175 in lucene-solr's branch refs/heads/master from Philippe Ouellet [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7a849f6 ] LUCENE-9354: Sync French stop words with latest version from Snowball. (#1474) * Sync French stop words with latest version from Snowball. This new version removed some French homonyms from the list * Use latest master commit from snowball-website * LUCENE-9354: regenerate with 'gradle snowball * LUCENE-9354: add CHANGES.txt entry > Refresh French stop words to remove homonyms > > > Key: LUCENE-9354 > URL: https://issues.apache.org/jira/browse/LUCENE-9354 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 8.5.1 >Reporter: Philippe >Priority: Minor > Labels: ready-to-commit > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sync French stop words with latest version from Snowball. > > This new version removed some French homonyms from the list -- 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=17097754#comment-17097754
]
Tomoko Uchida edited comment on LUCENE-9321 at 5/2/20, 12:16 AM:
-
As to precommit / javadoc linting, at the moment I don't simply understand why
it have to depend on "documentation" task. The only problem for that is
{{check-broken-link}}, "to check if all relative paths are effective"; we
already have dropped most of the relative paths in our Javadocs on LUCENE-9278
for clean-up, but there are still some links from "lucene-core" to child
modules. Instead of gathering all javedocs into one place and checking relative
links, could we fix the linting script to make it work with per-project folder
? In the script, I think we also can forbid someone to add relative links
(which strengthens interdependencies between sub-projects) any more. To me it
does not look a very big deal.
Other linting tasks in ant's "documentation-lint", {{ecjLint}} and
{{checkMissingDocs}} work fine with per-project javadoc folder.
was (Author: tomoko uchida):
As to precommit / javadoc linting, at the moment I don't simply understand why
it have to depend on "documentation" task. The only problem for that is
{{check-broken-link}}, "to check if all relative paths are effective"; we
already have dropped most of the relative paths in our Javadocs on LUCENE-9278
for clean-up, but there are still some links from "lucene-core" to child
modules. Instead of gathering and checking relative links, could we fix the
linting script to make it work with per-project folder ? In the script, I think
we also can forbid someone to add relative links (which strengthens
interdependencies between sub-projects) any more. To me it does not look a very
big deal.
Other linting tasks in ant's "documentation-lint", {{ecjLint}} and
{{checkMissingDocs}} work fine with per-project javadoc folder.
> 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
> Time Spent: 1h
> 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=17097754#comment-17097754
]
Tomoko Uchida commented on LUCENE-9321:
---
As to precommit / javadoc linting, at the moment I don't simply understand why
it have to depend on "documentation" task. The only problem for that is
{{check-broken-link}}, "to check if all relative paths are effective"; we
already have dropped most of the relative paths in our Javadocs on LUCENE-9278
for clean-up, but there are still some links from "lucene-core" to child
modules. Instead of gathering and checking relative links, could we fix the
linting script to make it work with per-project folder ? In the script, I think
we also can forbid someone to add relative links (which strengthens
interdependencies between sub-projects) any more. To me it does not look a very
big deal.
Other linting tasks in ant's "documentation-lint", {{ecjLint}} and
{{checkMissingDocs}} work fine with per-project javadoc folder.
> 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
> Time Spent: 1h
> 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
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1477: LUCENE-9321: Port markdown task to Gradle
uschindler commented on a change in pull request #1477:
URL: https://github.com/apache/lucene-solr/pull/1477#discussion_r418783252
##
File path: gradle/documentation/documentation.gradle
##
@@ -34,4 +36,11 @@ configure(subprojects.findAll { it.path == ':lucene' ||
it.path == ':solr' }) {
ext {
docroot = "${project.buildDir}/documentation"
}
+
+ task copyDocumentationAssets(type: Copy) {
+includeEmptyDirs = false
+from('site/html') // lucene
Review comment:
Here it's easy to separate, will do!
##
File path: gradle/documentation/markdown.gradle
##
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import com.vladsch.flexmark.util.ast.Document;
+import com.vladsch.flexmark.ast.Heading;
+import com.vladsch.flexmark.html.HtmlRenderer;
+import com.vladsch.flexmark.parser.Parser;
+import com.vladsch.flexmark.parser.ParserEmulationProfile;
+import com.vladsch.flexmark.util.sequence.Escaping;
+import com.vladsch.flexmark.util.data.MutableDataSet;
+import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension;
+import com.vladsch.flexmark.ext.autolink.AutolinkExtension;
+
+buildscript {
+ repositories {
+mavenCentral()
+ }
+
+ dependencies {
+def flexmarkVersion = '0.61.24'
+
+classpath 'com.vladsch.flexmark:flexmark:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-autolink:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-abbreviation:' +
flexmarkVersion
+ }
+}
+
+configure(subprojects.findAll { it.path == ':lucene' || it.path == ':solr' }) {
+ task markdownToHtml(type: Copy) {
+filteringCharset = 'UTF-8'
+includeEmptyDirs = false
+from('.') {// lucene
Review comment:
I was thinking about that too, but this was easier to begin with. I did
not want to clone the whole "Copy" task several times. If you tell me how to do
this easier, give me a hint!
Should I remove the `from` here and then add 2 separate configures for
lucene and solr just adding the `from`?
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] uschindler commented on a change in pull request #1477: LUCENE-9321: Port markdown task to Gradle
uschindler commented on a change in pull request #1477:
URL: https://github.com/apache/lucene-solr/pull/1477#discussion_r418783353
##
File path: gradle/documentation/markdown.gradle
##
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import com.vladsch.flexmark.util.ast.Document;
+import com.vladsch.flexmark.ast.Heading;
+import com.vladsch.flexmark.html.HtmlRenderer;
+import com.vladsch.flexmark.parser.Parser;
+import com.vladsch.flexmark.parser.ParserEmulationProfile;
+import com.vladsch.flexmark.util.sequence.Escaping;
+import com.vladsch.flexmark.util.data.MutableDataSet;
+import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension;
+import com.vladsch.flexmark.ext.autolink.AutolinkExtension;
+
+buildscript {
+ repositories {
+mavenCentral()
+ }
+
+ dependencies {
+def flexmarkVersion = '0.61.24'
+
+classpath 'com.vladsch.flexmark:flexmark:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-autolink:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-abbreviation:' +
flexmarkVersion
+ }
+}
+
+configure(subprojects.findAll { it.path == ':lucene' || it.path == ':solr' }) {
+ task markdownToHtml(type: Copy) {
+filteringCharset = 'UTF-8'
+includeEmptyDirs = false
+from('.') {// lucene
+ include 'MIGRATE.md'
+ include 'JRE_VERSION_MIGRATION.md'
+ include 'SYSTEM_REQUIREMENTS.md'
+}
+from('site') { // solr
+ include '**/*.md'
+}
+into project.docroot
+rename(/\.md$/, '.html')
+filter(MarkdownFilter)
+ }
+
+ task createDocumentationIndex {
+// nocommit: this needs to be implemented next
+ }
+}
+
+class MarkdownFilter extends FilterReader {
+ public MarkdownFilter(Reader reader) throws IOException {
+// this is a hack: it reads whole file, converts it and provides result as
a StringReader
Review comment:
It looks like misuse of a FilterReader, because you do everything in the
constructor.
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] uschindler commented on a change in pull request #1477: LUCENE-9321: Port markdown task to Gradle
uschindler commented on a change in pull request #1477:
URL: https://github.com/apache/lucene-solr/pull/1477#discussion_r418783252
##
File path: gradle/documentation/documentation.gradle
##
@@ -34,4 +36,11 @@ configure(subprojects.findAll { it.path == ':lucene' ||
it.path == ':solr' }) {
ext {
docroot = "${project.buildDir}/documentation"
}
+
+ task copyDocumentationAssets(type: Copy) {
+includeEmptyDirs = false
+from('site/html') // lucene
Review comment:
I was thinking about that too, but this was easier to begin with. I did
not want to clone the whole "Copy" task several times. If you tell me how to do
this easier, give me a hint!
Should I remove the `from` here and then add 2 separate configures for
lucene and solr just adding the `from`?
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_r418779981
##
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:
I'm testing it now.
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_r418779755
##
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:
So, I got pulled away by some work. I'll update. I think it makes sense
to drop the response before the close shield if possible.
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] 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_r418774258 ## File path: solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc ## @@ -64,6 +66,34 @@ There are several things defined in this example: <5> The 'admin' role has been defined, and it has permission to edit security settings. <6> The 'solr' user has been defined to the 'admin' role. +=== Example for ExternalRoleRuleBasedAuthorizationPlugin +This example `security.json` shows how an imagined `JWTAuthPlugin`, which pulls user and user roles from JWT claims, can work with the `ExternalRoleRuleBasedAuthorizationPlugin` plugin: Review comment: I brought back some of the refguide changes from the original patch. Please review again. 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] uschindler edited a comment on pull request #1479: LUCENE-9278: Improved options file creation
uschindler edited a comment on pull request #1479: URL: https://github.com/apache/lucene-solr/pull/1479#issuecomment-622603848 Example options file like created on my computer: ``` -overview 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java\\overview.html' -sourcepath 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java' -subpackages org.apache.lucene -d 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\build\\docs\\javadoc' -protected -encoding UTF-8 -charset UTF-8 -docencoding UTF-8 -noindex -author -version -use -locale en_US -windowtitle 'Lucene 9.0.0-SNAPSHOT core API' -doctitle 'Lucene 9.0.0-SNAPSHOT core API' -bottom 'Copyright © 2000-2020 Apache Software Foundation. All Rights Reserved.' -tag 'lucene.experimental:a:WARNING: This API is experimental and might change in incompatible ways in the next release.' -tag 'lucene.internal:a:NOTE: This API is for internal purposes only and might change in incompatible ways in the next release.' -tag 'lucene.spi:t:SPI Name (case-insensitive: if the name is \"htmlStrip\", \'htmlstrip\' can be used when looking up the service).' -linkoffline https://docs.oracle.com/en/java/javase/11/docs/api/ 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\tools\\javadoc\\java11' --release 11 -Xdoclint:all,-missing ``` (FYI: The double quotes around `htmlStrip` was just a test to have all variants tested) 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] uschindler edited a comment on pull request #1479: LUCENE-9278: Improved options file creation
uschindler edited a comment on pull request #1479: URL: https://github.com/apache/lucene-solr/pull/1479#issuecomment-622603848 Example options file like created on my computer: ``` -overview 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java\\overview.html' -sourcepath 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java' -subpackages org.apache.lucene -d 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\build\\docs\\javadoc' -protected -encoding UTF-8 -charset UTF-8 -docencoding UTF-8 -noindex -author -version -use -locale en_US -windowtitle 'Lucene 9.0.0-SNAPSHOT core API' -doctitle 'Lucene 9.0.0-SNAPSHOT core API' -bottom 'Copyright © 2000-2020 Apache Software Foundation. All Rights Reserved.' -tag 'lucene.experimental:a:WARNING: This API is experimental and might change in incompatible ways in the next release.' -tag 'lucene.internal:a:NOTE: This API is for internal purposes only and might change in incompatible ways in the next release.' -tag 'lucene.spi:t:SPI Name (case-insensitive: if the name is \"htmlStrip\", \'htmlstrip\' can be used when looking up the service).' -linkoffline https://docs.oracle.com/en/java/javase/11/docs/api/ 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\tools\\javadoc\\java11' --release 11 -Xdoclint:all,-missing ``` (FYI: The double quotes around `htmlStrip` was just a test to have all variants tested. 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-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097729#comment-17097729 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13289: -- Sounds good. I'll switch to boolean, and we can document that when not exact, it's always greater than. > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- 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] uschindler commented on pull request #1479: LUCENE-9278: Improved options file creation
uschindler commented on pull request #1479: URL: https://github.com/apache/lucene-solr/pull/1479#issuecomment-622603848 Example options file like created on my computer: ``` -overview 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java\\overview.html' -sourcepath 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\src\\java' -subpackages org.apache.lucene -d 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\core\\build\\docs\\javadoc' -protected -encoding UTF-8 -charset UTF-8 -docencoding UTF-8 -noindex -author -version -use -locale en_US -windowtitle 'Lucene 9.0.0-SNAPSHOT core API' -doctitle 'Lucene 9.0.0-SNAPSHOT core API' -bottom 'Copyright © 2000-2020 Apache Software Foundation. All Rights Reserved.' -tag 'lucene.experimental:a:WARNING: This API is experimental and might change in incompatible ways in the next release.' -tag 'lucene.internal:a:NOTE: This API is for internal purposes only and might change in incompatible ways in the next release.' -tag 'lucene.spi:t:SPI Name (case-insensitive: if the name is \"htmlStrip\", \'htmlstrip\' can be used when looking up the service).' -linkoffline https://docs.oracle.com/en/java/javase/11/docs/api/ 'C:\\Users\\Uwe Schindler\\Projects\\lucene\\trunk-lusolr1\\lucene\\tools\\javadoc\\java11' --release 11 -Xdoclint:all,-missing ``` 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] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456: URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418772556 ## File path: solr/core/src/java/org/apache/solr/response/JSONWriter.java ## @@ -132,11 +133,16 @@ public void writeSolrDocument(String name, SolrDocument doc, ReturnFields return // that the size could not be reliably determined. // + /** + * This method will be removed in Solr 9 Review comment: I really don't think we need to keep this around longer than 9.0. People upgrading a major version expect to have to change some code. This is a trivial change, they'll get a compile-time error and notice there is a new parameter added. This doesn't even change the client, just plugins. 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097726#comment-17097726 ] Uwe Schindler commented on LUCENE-9278: --- Here is a new PR: https://github.com/apache/lucene-solr/pull/1479 I like this much more, because the parameters are no longer concatted and instead you define them as a structure array of options with arguments. The escaper automatically escapes puts all arguments, which contain single/double quotes or whitespace, into single quotes and escapes all special characters inside. Any argument does not need to be a string, the conversion is done automatically. I will merge this tomorrow if nobody objects. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6h 40m > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-13132) Improve JSON "terms" facet performance when sorted by relatedness
[
https://issues.apache.org/jira/browse/SOLR-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097725#comment-17097725
]
Chris M. Hostetter commented on SOLR-13132:
---
{quote}... If you don't think it's a concern then it's no concern to me (other
than that preserving order seems achievable here..
{quote}
Since it's already impossible to ensure keys maintain consistent order as the
processor/options change, Let's deliberately not concern ourselves with
maintaining them if/when sweep is used in the interest in keeping the code
simpler.
(If/When someone cares about key order consistency down hte road, they'll have
to tackle it at a much higher level then just sweeping – and in theory can do
it after the buckets have been populated by re-ordering the key/val pairs)
{quote}...what would you think about modifying the method signature of
SlotAcc.setValues(SimpleOrderedMap bucket, int slotNum) to return
boolean instead of void, in the spirit of the setValues(...) method recently
added to the SweepingAcc class? Or maybe less invasive, adding an analogous
method to CountSlotAcc that returns boolean? ...
{quote}
Given that we seem to agree moving towards {{SweepingCountSlotAcc extends
CountSlotArrAcc}} as a replacement for {{SweepingAcc}} then id prefer we avoid
changing the {{CountSlotAcc}} API at all.
{quote}{quote}unless there's another use for CollectSlotAccMappingAware i'm
overlooking?
{quote}
The main/initial purpose of this was to provide an interface for notifying
FacetProcessors when SlotAccs had been swapped out. ...
{quote}
Ugh, sorry ... that was a half thought out idea that i phrased in the form of a
bad, and overly brief, question.
I understand the current usage of FacetFieldProcessorSlotAccMapper (as a
concrete implementation of CollectSlotAccMappingAware) that handles remapping
of the sortAcc – what i was mulling was...
* Assuming:
** we refactor CountSlotAcc's sweeping logic + SweepingAcc into a new
{{SweepingCountSlotAcc}}
** you have no other purpose/usecase in mind for CollectSlotAccMappingAware as
an API/abstraction
* Then:
** {{SweepingCountSlotAcc}} 's constructor could take in the
{{FacetFieldProcessor}} ('this') directly
** {{SweepingCountSlotAcc}} 's version of {{registerMapping()}} could directly
manipulate {{processor.sortAcc}} when/if it gets mapped
...but as i said: that idea was half thought out, it's a refactoring to
consider down the road depending on how some of hte other more significant API
discussions we've been having shake out. Don't worry about it.
{quote}... but I agree and I think your suggestion of "Perhaps a single
initSweeping(CollectSlotAccMappingAware notify) for use by processors, that
fails if called more then once? All other code paths use getBaseSweepingAcc()"
is a good way forward. I was waiting to address that until after discussion of
these other questions.
{quote}
But we shouldn't actually need either of those methods anymore if we go the
{{SweepingCountSlotAcc}} route ... correct?
* {{countAcc.initSweeping(notify)}} can now just be {{countAcc = new
SweepingCountSlotAcc(...)}}
* {{countAcc.getBaseSweepingAcc()}} can now just be:
** {{(SweepingCountSlotAcc)countAcc}} when passed as an arg to
{{SweepableAcc.registerSweepingAccs(...)}} or when doing the actual sweeping
** {{countAcc}} when the purpose is to call {{setValues}} (from
FacetFieldProcessor, which should no longer need to have any idea that sweeping
is even a concept)
...right?
{quote}This seems reasonable. If you don't mind, I can take a crack at seeing
what this might look like. I'm particularly interested in doing this in a way
that keeps the "sweeping" stuff modular (under the hood, at least), since it's
possible that other concrete CountSlotAcc subclasses (whose core "count"
functionality is substantially different) could still use the exact same code
for coordinating sweeping. (I'm thinking particularly about cached counts ...
definitely conscious of not having that bleed into this issue, just trying to
be transparent!).
{quote}
Sure, go for it – but i would urge you not to go too overboard on modularity at
this point: if all the details are nicely encapsulated inside a single new
{{SweepingCountSlotAcc}} we can always refactor them out into more modular
classes later if/when there is a need for that modularity.
In the same spirit of being transparent: I'm trying to keep the number of code
paths touched by these changes (and the number of new APIS/abstractions/etc...)
at a minimum in order to increase confidence in the correctness and reduce the
likelihood of introducing bugs or unforseen side effects. (I'd rather focus on
releasing a bicycle soon, and later have a dicussion about refactoring it into
a car; then stall on releasing a bicycle while we spend a lot of time
pre-planning for a future car)
Also: we should update your branch to mer
[GitHub] [lucene-solr] uschindler opened a new pull request #1479: LUCENE-9278: Improved options file creation
uschindler opened a new pull request #1479: URL: https://github.com/apache/lucene-solr/pull/1479 Improved version of the options file creator in the renderJavadocs task: All parameters are escaped automatically, arguments don't need to be strings (they are converted during building options file). This makes it easy to use (adding new options) and e.g., filenames are escaped correctly 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] janhoy commented on pull request #341: SOLR-12131: ExternalRoleRuleBasedAuthorizationPlugin
janhoy commented on pull request #341: URL: https://github.com/apache/lucene-solr/pull/341#issuecomment-622592651 > Wait, what happened to the ref guide changes? Hmm, will try to get them back 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] madrob commented on a change in pull request #341: SOLR-12131: ExternalRoleRuleBasedAuthorizationPlugin
madrob commented on a change in pull request #341: URL: https://github.com/apache/lucene-solr/pull/341#discussion_r418758313 ## File path: solr/core/src/test/org/apache/solr/security/PrincipalWithUserRoles.java ## @@ -0,0 +1,93 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.solr.security; + +import java.security.Principal; +import java.util.Objects; +import java.util.Set; + +import org.apache.http.util.Args; Review comment: nit: I think precommit will fail on this unused import. 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] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418756851
##
File path:
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
##
@@ -401,6 +403,14 @@ public void process(ResponseBuilder rb) throws IOException
doProcessUngroupedSearch(rb, cmd, result);
}
+ private int getMinExactHits(SolrParams params) {
+long minExactHits = params.getLong(CommonParams.MIN_EXACT_HITS,
Integer.MAX_VALUE);
+if (minExactHits < 0 || minExactHits > Integer.MAX_VALUE) {
Review comment:
This is intentional. See the discussion with Adrien in this same PR. We
allow longs just because the `minExactHits` is in relation to the `numFound`,
which is a long, however, any value greater than `Integer.MAX_VALUE` doesn't
make sense, since Lucene doesn't allow more than that in a single shard. In
case of distributed queries, the `minExactHits` is used by every shard
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] anshumg commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
anshumg commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418678327
##
File path:
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
##
@@ -401,6 +403,14 @@ public void process(ResponseBuilder rb) throws IOException
doProcessUngroupedSearch(rb, cmd, result);
}
+ private int getMinExactHits(SolrParams params) {
+long minExactHits = params.getLong(CommonParams.MIN_EXACT_HITS,
Integer.MAX_VALUE);
+if (minExactHits < 0 || minExactHits > Integer.MAX_VALUE) {
Review comment:
This doesn't really allow anyone to specify a minExactHits value between
Integer.MAX_VALUE and Long.MAX_VALUE. For practical reasons, that is ok but
just not consistent and would require a note in the ref guide too. Do you think
we should just switch this out with Long instead?
##
File path: solr/core/src/java/org/apache/solr/response/JSONWriter.java
##
@@ -132,11 +133,16 @@ public void writeSolrDocument(String name, SolrDocument
doc, ReturnFields return
// that the size could not be reliably determined.
//
+ /**
+ * This method will be removed in Solr 9
Review comment:
This method will be removed `after` Solr 9, right?
##
File path: solr/core/src/test/org/apache/solr/request/TestFaceting.java
##
@@ -931,5 +934,28 @@ public void testListedTermCounts() throws Exception {
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[2][@name='Book2']",
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[3][@name='Book3']");
}
+
+ @Test
+ public void testFacetCountsWithMinExactHits() throws Exception {
+final int NUM_DOCS = 20;
+for (int i = 0; i < NUM_DOCS ; i++) {
+ assertU(adoc("id", String.valueOf(i), "title_ws", "Book1"));
+ assertU(commit());
Review comment:
We can move this commit out of the loop and just commit once.
##
File path: solr/core/src/test/org/apache/solr/TestDistributedSearch.java
##
@@ -1082,11 +1086,32 @@ public void test() throws Exception {
assertEquals(new EnumFieldValue(11, "Critical"),
rsp.getFieldStatsInfo().get(fieldName).getMax());
-handle.put("severity", UNORDERED); // this is stupid, but stats.facet
doesn't garuntee order
+handle.put("severity", UNORDERED); // this is stupid, but stats.facet
doesn't guarantee order
query("q", "*:*", "stats", "true", "stats.field", fieldName,
"stats.facet", fieldName);
}
+ private void testMinExactHits() throws Exception {
+assertIsExactHitCount("q","{!cache=false}dog OR men OR cow OR country OR
dumpty", CommonParams.MIN_EXACT_HITS, "200", CommonParams.ROWS, "2",
CommonParams.SORT, "score desc, id asc");
Review comment:
:)
##
File path: solr/core/src/test/org/apache/solr/request/TestFaceting.java
##
@@ -931,5 +934,28 @@ public void testListedTermCounts() throws Exception {
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[2][@name='Book2']",
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[3][@name='Book3']");
}
+
+ @Test
+ public void testFacetCountsWithMinExactHits() throws Exception {
+final int NUM_DOCS = 20;
+for (int i = 0; i < NUM_DOCS ; i++) {
+ assertU(adoc("id", String.valueOf(i), "title_ws", "Book1"));
+ assertU(commit());
+}
+ModifiableSolrParams params = new ModifiableSolrParams();
+params.set("q", "title_ws:Book1");
+params.set(FacetParams.FACET, "true");
+params.set(FacetParams.FACET_FIELD, "title_ws");
+assertQ(req(params),
+
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[1][@name='Book1'][.='20']"
+,"//*[@hitCountRelation='" + HitCountRelation.EQ + "']"
+,"//*[@numFound='" + NUM_DOCS + "']");
+
+// It doesn't matter if we request munExactHits, when requesting facets,
the numFound value is precise
Review comment:
munExactHits -> numExactHits
##
File path: solr/core/src/test/org/apache/solr/search/SolrIndexSearcherTest.java
##
@@ -0,0 +1,200 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.search;
+
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456: URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418752582 ## File path: solr/core/src/java/org/apache/solr/search/QueryResultKey.java ## @@ -65,6 +70,7 @@ public QueryResultKey(Query query, List filters, Sort sort, int nc_flags) h = h*29 + sf.hashCode(); ramSfields += BASE_SF_RAM_BYTES_USED + RamUsageEstimator.sizeOfObject(sf.getField()); } +h = h*31 + minExactHits; Review comment: ah! Good question. I guess yes? 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] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418750165
##
File path: solr/core/src/java/org/apache/solr/search/MaxScoreCollector.java
##
@@ -37,9 +37,7 @@ public float getMaxScore() {
@Override
public ScoreMode scoreMode() {
-// Should be TOP_SCORES but this would wrap the scorer unnecessarily since
-// this collector is only used in a MultiCollector.
-return ScoreMode.COMPLETE;
+return ScoreMode.TOP_SCORES;
Review comment:
There is a previous discussion in this PR about it:
> tflobbe:
> @jpountz, What did you mean with this comment? MultiCollector will set the
scoreMode to COMPLETE in the case of the main collector being something other
than TOP_SCORES, right?
> jpountz:
> Yeah I think that at some point we tried not to wrap the scorer when all
score modes were COMPLETE but apparently now we do, so this comment is stale.
https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/MultiCollector.java#L158
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-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097689#comment-17097689 ] David Smiley commented on SOLR-13289: - Yeah; lets just go with a simple-to-understand boolean. Even if we do ultimately add more tuning nobs or whatever, this boolean would still be factually correct. > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- 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] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456: URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418749058 ## File path: solr/core/src/java/org/apache/solr/response/JSONWriter.java ## @@ -132,11 +133,16 @@ public void writeSolrDocument(String name, SolrDocument doc, ReturnFields return // that the size could not be reliably determined. // + /** + * This method will be removed in Solr 9 Review comment: My understanding is that it's OK to change methods across major versions? Unless it's something needed for rolling upgrade or something. 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] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418748102
##
File path:
solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
##
@@ -292,11 +293,18 @@ else if(geo instanceof WriteableGeoJSON) {
}
}
+ @Deprecated
@Override
public void writeStartDocumentList(String name,
- long start, int size, long numFound, Float maxScore) throws IOException
+ long start, int size, long numFound, Float maxScore) throws IOException {
+throw new UnsupportedOperationException();
Review comment:
This method Shouldn't be called at all for writing a response. In other
ResponseWriters, I left the code untouched for support in case someone is
extending the Writer. In this case, since it's an inner class, I decided to
throw an exception to catch potential bugs (internal code calling this)
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-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=17097683#comment-17097683
]
Michael Gibney commented on SOLR-14454:
---
[PR #1478|https://github.com/apache/lucene-solr/pull/1478] adds support in
three phases.
#
[aaf3bf1c|https://github.com/apache/lucene-solr/pull/1478/commits/aaf3bf1c3b98eab087991371a3a88dcd56274090]
introduces minimal changes that extend {{useDocValuesAsStored}} and
{{/export}} support for custom utf8 field types with {{DocValuesType.BINARY}}
#
[409cb811|https://github.com/apache/lucene-solr/pull/1478/commits/409cb81120066adda5ddb58abfc5b2166dc89c7e]
adds a concrete implementation that simply writes the raw utf8 binary
representation to binary docValues
#
[462a9a7e|https://github.com/apache/lucene-solr/pull/1478/commits/462a9a7ecf32132369052ae0f82075975f5f7cbd]
extends the simple implementation to support per-value, configurable Deflate
compression of binary docValues
> 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] madrob commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
madrob commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r418739528
##
File path:
solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
##
@@ -292,11 +293,18 @@ else if(geo instanceof WriteableGeoJSON) {
}
}
+ @Deprecated
@Override
public void writeStartDocumentList(String name,
- long start, int size, long numFound, Float maxScore) throws IOException
+ long start, int size, long numFound, Float maxScore) throws IOException {
+throw new UnsupportedOperationException();
Review comment:
Why? We can't pick a default and still use this?
##
File path: solr/core/src/java/org/apache/solr/response/JSONWriter.java
##
@@ -132,11 +133,16 @@ public void writeSolrDocument(String name, SolrDocument
doc, ReturnFields return
// that the size could not be reliably determined.
//
+ /**
+ * This method will be removed in Solr 9
Review comment:
do you mean solr 10? we don't need a major version with it deprecated
before we can jettison it? folks upgrading from 8.5->9 might be surprised by
this.
##
File path: solr/core/src/java/org/apache/solr/search/QueryResultKey.java
##
@@ -65,6 +70,7 @@ public QueryResultKey(Query query, List filters, Sort
sort, int nc_flags)
h = h*29 + sf.hashCode();
ramSfields += BASE_SF_RAM_BYTES_USED +
RamUsageEstimator.sizeOfObject(sf.getField());
}
+h = h*31 + minExactHits;
Review comment:
this is going to overflow in the default case, is that ok?
##
File path: solr/core/src/java/org/apache/solr/search/MaxScoreCollector.java
##
@@ -37,9 +37,7 @@ public float getMaxScore() {
@Override
public ScoreMode scoreMode() {
-// Should be TOP_SCORES but this would wrap the scorer unnecessarily since
-// this collector is only used in a MultiCollector.
-return ScoreMode.COMPLETE;
+return ScoreMode.TOP_SCORES;
Review comment:
why can we make this change?
##
File path: solr/core/src/test/org/apache/solr/request/TestFaceting.java
##
@@ -931,5 +934,28 @@ public void testListedTermCounts() throws Exception {
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[2][@name='Book2']",
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[3][@name='Book3']");
}
+
+ @Test
+ public void testFacetCountsWithMinExactHits() throws Exception {
+final int NUM_DOCS = 20;
+for (int i = 0; i < NUM_DOCS ; i++) {
+ assertU(adoc("id", String.valueOf(i), "title_ws", "Book1"));
+ assertU(commit());
+}
+ModifiableSolrParams params = new ModifiableSolrParams();
+params.set("q", "title_ws:Book1");
+params.set(FacetParams.FACET, "true");
+params.set(FacetParams.FACET_FIELD, "title_ws");
+assertQ(req(params),
+
"//lst[@name='facet_fields']/lst[@name='title_ws']/int[1][@name='Book1'][.='20']"
+,"//*[@hitCountRelation='" + HitCountRelation.EQ + "']"
+,"//*[@numFound='" + NUM_DOCS + "']");
+
+// It doesn't matter if we request munExactHits, when requesting facets,
the numFound value is precise
Review comment:
s/mun/min
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] magibney opened a new pull request #1478: SOLR-14454: support for UTF-8 (string) types with DocValuesType.BINARY
magibney opened a new pull request #1478: URL: https://github.com/apache/lucene-solr/pull/1478 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] [Created] (SOLR-14454) support for UTF-8 (string) types with DocValuesType.BINARY
Michael Gibney created SOLR-14454:
-
Summary: 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
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-13289) Support for BlockMax WAND
[
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097678#comment-17097678
]
Mike Drob commented on SOLR-13289:
--
Based on my understanding, I favor the boolean approach.
The only knob we have is a threshold, not an error bound, right? As in, if
there are more than X results, it's ok to return an estimate that may be too
low. We don't get to specify that we need the estimate to be within 10% or 1%
or whatever of the actual result, which is what precision would imply.
I like [~sokolov]'s comment about {{hitCountExact}}, that makes sense to me,
but there's lots of options here.
Specific comments left on the PR.
> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-13289.patch, SOLR-13289.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to
> expose this via Solr. When enabled, the numFound returned will not be exact.
--
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-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
[ https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097668#comment-17097668 ] Mike Drob commented on SOLR-10814: -- [~hgadre] - do you have any interest in picking this up again? I'd be happy to help review and get it included. > Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos > authentication > --- > > Key: SOLR-10814 > URL: https://issues.apache.org/jira/browse/SOLR-10814 > Project: Solr > Issue Type: Bug >Affects Versions: 6.2 >Reporter: Hrishikesh Gadre >Priority: Major > Attachments: SOLR-10814.patch > > > Solr allows configuring roles to control user access to the system. This is > accomplished through rule-based permission definitions which are assigned to > users. > The authorization framework in Solr passes the information about the request > (to be authorized) using an instance of AuthorizationContext class. Currently > the only way to extract authenticated user is via getUserPrincipal() method > which returns an instance of java.security.Principal class. The > RuleBasedAuthorizationPlugin implementation invokes getName() method on the > Principal instance to fetch the list of associated roles. > https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156 > In case of basic authentication mechanism, the principal is the userName. > Hence it works fine. But in case of kerberos authentication, the user > principal also contains the RELM information e.g. instead of foo, it would > return f...@example.com. This means if the user changes the authentication > mechanism, he would also need to change the user-role mapping in > authorization section to use f...@example.com instead of foo. This is not > good from usability perspective. -- 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-9355) missing releases from testbackwardscompatibility
Mike Drob created LUCENE-9355:
-
Summary: missing releases from testbackwardscompatibility
Key: LUCENE-9355
URL: https://issues.apache.org/jira/browse/LUCENE-9355
Project: Lucene - Core
Issue Type: Test
Reporter: Mike Drob
I'm not sure what needs to be added for the 7.7.3 release, but can you take a
look at it [~noble] or figure out who to ask for help?
{noformat}
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 7.7.3
[smoker] Traceback (most recent call last):
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1487, in
[smoker] main()
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1413, in main
[smoker] downloadOnly=c.download_only)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1465, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, gitRevision, version, testArgs, baseURL)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 566, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
gitRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 752, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1388, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
{noformat}
--
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_r418725066
##
File path:
solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPluginBase.java
##
@@ -0,0 +1,270 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+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.Arrays;
+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.CommandOperation;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.common.util.ValidatingJsonMap;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+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;
+
+/**
+ * Base class for rule based authorization plugins
+ */
+public abstract class RuleBasedAuthorizationPluginBase implements
AuthorizationPlugin, ConfigEditablePlugin, SpecProvider {
Review comment:
I brought it up to date now. The base class is a copy of the old RBAC
class, minus the user-roles map. Instead it delegates the role fecthing to the
sub classes.
The new RuleBasedAuthorizationPlugin.java is now very slim, mainly dealing
with parsing roles from security.json.
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-13132) Improve JSON "terms" facet performance when sorted by relatedness
[
https://issues.apache.org/jira/browse/SOLR-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097660#comment-17097660
]
Michael Gibney commented on SOLR-13132:
---
I was worrying about the order of sort keys out of an excess of caution,
figuring that if it was possible to preserve order, it'd be worth doing so. If
you don't think it's a concern then it's no concern to me (other than that
preserving order seems achievable here, and might not be a _bad_ thing :)).
{quote}cleaning the code up to consistently use countAcc.setValues(...) so we
can override it is a better approach. if the caller also needs to use
countAcc.getCount(...) to decide when to recurse, so be it.
{quote}
This makes sense to me. The above is also related to the question raised here:
{code:java}
// nocommit: if we're not using sweeping, why do we need to register
any mappings?
// baseSweepingAcc.registerMapping(this, this);
{code}
... indeed we probably could skip this if splitting full-domain accs between
{{SweepingAcc}} and {{collectAcc}}. The reason I left this in initially was
partly to preserve key order, but also to help clarify behavior of
{{registerSweepingAccs(...)}}; specifically, if a processor calls
{{registerSweepingAccs()}} on a {{SlotAcc}}, then the caller assumes
responsibility of mediating all the output (calls to {{setValues(...)}}) for
that acc. Now brainstorming other possible reasons to do this (aside from
preserving key order), I can't really come up with anything. _If_ there's still
any interest in preserving order, what would you think about modifying the
method signature of {{SlotAcc.setValues(SimpleOrderedMap bucket, int
slotNum)}} to return boolean instead of void, in the spirit of the
{{setValues(...)}} method recently added to the {{SweepingAcc}} class? Or maybe
less invasive, adding an analogous method to {{CountSlotAcc}} that returns
boolean? The return value would normally be false, but if "true", would
indicate that the method had handled setting values on all full-domain accs
(what would formerly have been covered by calling
{{collectAcc.setValues(...)}})?
{quote}unless there's another use for CollectSlotAccMappingAware i'm
overlooking?
{quote}
The main/initial purpose of this was to provide an interface for notifying
FacetProcessors when SlotAccs had been swapped out. Take the case where
{{sortAcc}} is aliased to an instance of {{SKGSlotAcc}} which is wrapped in a
{{MultiAcc}} {{collectAcc}}. {{collectAcc.registerSweepingAccs(...)}} could
return itself (no top-level change -- still containing the other SlotAccs that
need full collection, but with {{SKGSlotAcc}} removed). The new
{{SweepSKGSlotAcc}} would be registered with the {{SweepingAcc}} (or
potentially {{SweepingCountSlotAcc}}), but would still need to register the
SlotAcc replacement with the {{FacetProcessor}} so that it could make
corresponding changes to {{sortAcc}} or other aliases. In any case I think it's
still necessary for a SlotAcc that replaces itself to separately register a new
read-access instance with the {{SweepingAcc}} (or {{SweepingCountSlotAcc}}),
since the return value of {{registerSweepingAccs(...)}} is used to modify
"write" access (on the {{collectAcc}}).
{quote}CountSlotAcc.getBaseSweepingAcc(...) really messy and code-smell-ish
right now
{quote}
Ah, yeah. I'm sorry I didn't explicitly address the nocommit comment about
that, but I agree and I think your suggestion of "Perhaps a single
initSweeping(CollectSlotAccMappingAware notify) for use by processors, that
fails if called more then once? All other code paths use getBaseSweepingAcc()"
is a good way forward. I was waiting to address that until after discussion of
these other questions.
{quote}SweepingCountSlotAcc extends CountSlotArrAcc ... a new concrete
CountSlotAcc subclass
{quote}
This seems reasonable. If you don't mind, I can take a crack at seeing what
this might look like. I'm particularly interested in doing this in a way that
keeps the "sweeping" stuff modular (under the hood, at least), since it's
possible that other concrete {{CountSlotAcc}} subclasses (whose core "count"
functionality is substantially different) could still use the exact same code
for coordinating sweeping. (I'm thinking particularly about cached counts ...
definitely conscious of not having that bleed into this issue, just trying to
be transparent!).
> Improve JSON "terms" facet performance when sorted by relatedness
> --
>
> Key: SOLR-13132
> URL: https://issues.apache.org/jira/browse/SOLR-13132
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 7.4, master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Attachments: SOLR-13132-with-ca
[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_r418722327
##
File path:
solr/core/src/java/org/apache/solr/security/PrincipalWithUserRoles.java
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.security;
+
+import java.io.Serializable;
+import java.security.Principal;
+import java.util.Set;
+
+import org.apache.http.util.Args;
+
+/**
+ * Type of Principal object that can contain also a list of roles the user has.
+ * One use case can be to keep track of user-role mappings in an Identity
Server
+ * external to Solr and pass the information to Solr in a signed JWT token or
in
+ * another secure manner. The role information can then be used to authorize
+ * requests without the need to maintain or lookup what roles each user
belongs to.
+ */
+public class PrincipalWithUserRoles implements Principal, VerifiedUserRoles,
Serializable {
+ private static final long serialVersionUID = 4144666467522831388L;
+ private final String username;
+
+ private final Set roles;
+
+ /**
+ * User principal with user name as well as one or more roles that he/she
belong to
+ * @param username string with user name for user
+ * @param roles a set of roles that we know this user belongs to, or empty
list for no roles
+ */
+ public PrincipalWithUserRoles(final String username, Set roles) {
+super();
+Args.notNull(username, "User name");
Review comment:
Fixed
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] 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_r418721727
##
File path:
solr/core/src/java/org/apache/solr/security/PrincipalWithUserRoles.java
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.security;
+
+import java.io.Serializable;
+import java.security.Principal;
+import java.util.Set;
+
+import org.apache.http.util.Args;
+
+/**
+ * Type of Principal object that can contain also a list of roles the user has.
+ * One use case can be to keep track of user-role mappings in an Identity
Server
+ * external to Solr and pass the information to Solr in a signed JWT token or
in
+ * another secure manner. The role information can then be used to authorize
+ * requests without the need to maintain or lookup what roles each user
belongs to.
+ */
+public class PrincipalWithUserRoles implements Principal, VerifiedUserRoles,
Serializable {
Review comment:
This class is in test scope, so no big deal. I removed Serializable
though.
Real world Principal classes would implement VerifiedUserRoles directly
instead of having to use or subclass this one
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] madrob commented on a change in pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query
madrob commented on a change in pull request #1371:
URL: https://github.com/apache/lucene-solr/pull/1371#discussion_r418718546
##
File path:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
##
@@ -128,6 +128,28 @@ field collapsing (with ngroups) when the number of
distinct groups
public static final String HINT_TOP_FC = "top_fc";
public static final String HINT_MULTI_DOCVALUES = "multi_docvalues";
+ public enum NullPolicy {
+IGNORE("ignore", 0),
Review comment:
Can we get rid of the earlier String declarations too? Lines 125-127?
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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097638#comment-17097638 ] Uwe Schindler commented on LUCENE-9278: --- Sorry map won't work, but similar data structure. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097637#comment-17097637 ] Uwe Schindler commented on LUCENE-9278: --- bq. We can build the options file with their API but I think what Tomoko did is much more straightforward than trying to grasp what gradle folks do. And file name escaping is really not such a biggie (hey, you did it in no time). I found the option building just hard to read an error prone. I am sure that anybody who adds a new option may break it again. So my proposal would be to use a map with option name as key and a string as value. Then you can just put all options on the map (options without argument could use null or empty string as value). At the end where the current list is serialized by joining with newlines, I would just serialize the map, escaping all values. I will make a simple PR. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097635#comment-17097635 ] Uwe Schindler commented on LUCENE-9278: --- The standard doclet issue is the typical behaviour of Gradle developers. They hurt the Java ecosystem! They just do broken stuff in their code and then refuse to fix it. As you said: if they don't like timestamps they should not force everybody to not have them. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097628#comment-17097628 ] Dawid Weiss commented on LUCENE-9278: - Gradle javadoc task sucks in many ways... And it's not constant over time - they fiddle with defaults [1]. We can build the options file with their API but I think what Tomoko did is much more straightforward than trying to grasp what gradle folks do. And file name escaping is really not such a biggie (hey, you did it in no time). [1] https://github.com/gradle/gradle/issues/11898 > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097619#comment-17097619 ] Uwe Schindler commented on LUCENE-9278: --- I have to look it up. The source code of Ant mentions it. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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] 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_r418689669
##
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:
Not in its current state because response object won't exist, but I
could refactor if you have a good reason for that. Or, if I think of one. Gonna
peep those methods again now.
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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097610#comment-17097610 ] Uwe Schindler commented on LUCENE-9278: --- IMHO to improve this, we should build the options file with the corresponding Gradle API (they have a whole package just to produce this option files). My fix above was just an easy escaper after adding single quotes around all params. I don't like current code as it's hard to read, maybe we should really build the option file using the Gradle API. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097605#comment-17097605 ] Uwe Schindler commented on LUCENE-9278: --- Exactly! See my comment, too. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097606#comment-17097606 ] Dawid Weiss commented on LUCENE-9278: - bq. The issue is already solved, for background read the specs by Oracle Where is this spec you're talking about? Couldn't find it. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097602#comment-17097602
]
Dawid Weiss commented on LUCENE-9278:
-
Answering myself: it can be a regular Windows path (with backslashes) unless
it's quoted... then backslashes are interpreted as escape sequences. So these
are equivalent:
{code}
-overview c:\foo\bar\overview.html
-overview "c:\\foo\\bar\\overview.html"
{code}
White space requires quotes though.
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097599#comment-17097599 ] Uwe Schindler commented on LUCENE-9278: --- The issue is already solved, for background read the specs by Oracle. In short: if the option contains whitespace, it must be surrounded by single quotes. Once you do this, also escaping gets enabled, so backslashes must be doubled and single quotes must be escaped. That's what the merged PR is doing. If you check the options files generated by ant, you can easily see that. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097594#comment-17097594 ] Dawid Weiss commented on LUCENE-9278: - I'm on Windows and backslashes work(ed) just fine for me in those option files?... What gives? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-14430) Authorization plugins should check roles from request
[
https://issues.apache.org/jira/browse/SOLR-14430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097593#comment-17097593
]
Jan Høydahl commented on SOLR-14430:
I’m not currently working on this feature, so feel free to build on and
improve/simplify my ideas.
> Authorization plugins should check roles from request
> -
>
> Key: SOLR-14430
> URL: https://issues.apache.org/jira/browse/SOLR-14430
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Priority: Major
>
> The AuthorizationContext exposes {{getUserPrincipal}} to the plugin, but it
> does not allow the plugin to interrogate the request for {{isUserInRole}}. If
> we trust the request enough to get a principal from it, then we should trust
> it enough to ask about roles, as those could have been defined and verified
> by an authentication plugin.
> This model would be an alternative to the current model where
> RuleBasedAuthorizationPlugin maintains its own user->role mapping.
--
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=17097586#comment-17097586 ] Dawid Weiss commented on LUCENE-9321: - bq. So why are you arguing to have the javadocs splattered around the build tree? Hmm... Personal preference? Something about consolidated top-level "docs" folder just stinks to me. We can validate and lint docs where they are within the project. I don't think final packaging has anything to do with it - you just assemble the javadocs you wish to assemble and put an index file on top, done. If you really, really badly want that single documentation folder then be my guest but I don't think it's elegant. > 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 > Time Spent: 0.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
[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_r418677843 ## File path: solr/bin/solr.cmd ## @@ -1288,6 +1295,7 @@ REM '-OmitStackTraceInFastThrow' ensures stack traces in errors, REM users who don't care about useful error msgs can override in SOLR_OPTS with +OmitStackTraceInFastThrow set "START_OPTS=%START_OPTS% -XX:-OmitStackTraceInFastThrow" set START_OPTS=%START_OPTS% !GC_TUNE! %GC_LOG_OPTS% +set START_OPTS=-DdisableAdminUI=%DISABLE_ADMIN_UI% Review comment: I believe this one is fixed as well @madrob 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] (SOLR-11936) maven urls should use https
[ https://issues.apache.org/jira/browse/SOLR-11936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob resolved SOLR-11936. -- Resolution: Duplicate > maven urls should use https > --- > > Key: SOLR-11936 > URL: https://issues.apache.org/jira/browse/SOLR-11936 > Project: Solr > Issue Type: Task >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-11936.patch > > > using http can lead to a bad download, should use https instead -- 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] 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_r418671239 ## File path: solr/bin/solr ## @@ -2097,6 +2097,14 @@ else SECURITY_MANAGER_OPTS=() fi +# Enable ADMIN UI by default, and give the option for users to disable it +if [ "$SOLR_ADMIN_UI_DISABLED" == "true" ]; then + SOLR_ADMIN_UI="-DdisableAdminUI=true" + echo -e "ADMIN UI Disabled" +else + SOLR_ADMIN_UI="-DdisableAdminUI=false" Review comment: https://github.com/apache/lucene-solr/pull/1471/commits/dedcdfe8b9af18d1a4662937be96b4d710963826 @madrob 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] [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=17097573#comment-17097573 ] Uwe Schindler edited comment on LUCENE-9321 at 5/1/20, 6:21 PM: Sorry I still disagree with this: - On Windows it takes minutes to copy the stuff to one place. In addition the whole Javadocs is hundreds of megabytes and I don't want them 2 times on my computer, just for packagaing AND linting purposes! - The precommit / javadoc-lint task (as discussed with [~rcmuir] before in the other issue) is there to validate the links and the javadocs as a whole. Just to run this task I see no reason to copy all of this around. In short: There's no problem in changing the JavaPlugin's javadocs output folder to place eventhing at a different target location. In addition, the "gradle clean" folder does everything correct. So what's the issue to change th output? The Maven packaging should also have no problem with that. So why are you arguing to have the javadocs splattered around the build tree? was (Author: thetaphi): Sorry I still disagree with this: - On Windows it takes minutes to copy the stuff to one place. In addition the whole Javadocs is hundreds of megabytes and I don't want them 2 times on my computer, just for packagaing AND linting purposes! - The precommit / javadoc-lint task (as discussed with [~rcmuir] before in the other issue) is there to validate the links and the javadocs as a whole. Just to run this task I see no reason to copy all of this around. In short: There's no problem in changing the JavaPlugin's javadocs output folder to place eventhing at a different target location. Even the "gradle clean" folder does everything correct. So what's the issue to change th output? The Maven packaging should also have no problem with that. So why are you arguing to have the javadocs splattered around the build tree? > 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 > Time Spent: 0.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=17097573#comment-17097573 ] Uwe Schindler commented on LUCENE-9321: --- Sorry I still disagree with this: - On Windows it takes minutes to copy the stuff to one place. In addition the whole Javadocs is hundreds of megabytes and I don't want them 2 times on my computer, just for packagaing AND linting purposes! - The precommit / javadoc-lint task (as discussed with [~rcmuir] before in the other issue) is there to validate the links and the javadocs as a whole. Just to run this task I see no reason to copy all of this around. In short: There's no problem in changing the JavaPlugin's javadocs output folder to place eventhing at a different target location. Even the "gradle clean" folder does everything correct. So what's the issue to change th output? The Maven packaging should also have no problem with that. So why are you arguing to have the javadocs splattered around the build tree? > 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 > Time Spent: 0.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
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1477: LUCENE-9321: Port markdown task to Gradle
dweiss commented on a change in pull request #1477:
URL: https://github.com/apache/lucene-solr/pull/1477#discussion_r418669624
##
File path: gradle/documentation/markdown.gradle
##
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import com.vladsch.flexmark.util.ast.Document;
+import com.vladsch.flexmark.ast.Heading;
+import com.vladsch.flexmark.html.HtmlRenderer;
+import com.vladsch.flexmark.parser.Parser;
+import com.vladsch.flexmark.parser.ParserEmulationProfile;
+import com.vladsch.flexmark.util.sequence.Escaping;
+import com.vladsch.flexmark.util.data.MutableDataSet;
+import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension;
+import com.vladsch.flexmark.ext.autolink.AutolinkExtension;
+
+buildscript {
+ repositories {
+mavenCentral()
+ }
+
+ dependencies {
+def flexmarkVersion = '0.61.24'
+
+classpath 'com.vladsch.flexmark:flexmark:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-autolink:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-abbreviation:' +
flexmarkVersion
+ }
+}
+
+configure(subprojects.findAll { it.path == ':lucene' || it.path == ':solr' }) {
+ task markdownToHtml(type: Copy) {
+filteringCharset = 'UTF-8'
+includeEmptyDirs = false
+from('.') {// lucene
+ include 'MIGRATE.md'
+ include 'JRE_VERSION_MIGRATION.md'
+ include 'SYSTEM_REQUIREMENTS.md'
+}
+from('site') { // solr
+ include '**/*.md'
+}
+into project.docroot
+rename(/\.md$/, '.html')
+filter(MarkdownFilter)
+ }
+
+ task createDocumentationIndex {
+// nocommit: this needs to be implemented next
+ }
+}
+
+class MarkdownFilter extends FilterReader {
+ public MarkdownFilter(Reader reader) throws IOException {
+// this is a hack: it reads whole file, converts it and provides result as
a StringReader
Review comment:
Looks legit to me, not a hack? :)
##
File path: gradle/documentation/markdown.gradle
##
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import com.vladsch.flexmark.util.ast.Document;
+import com.vladsch.flexmark.ast.Heading;
+import com.vladsch.flexmark.html.HtmlRenderer;
+import com.vladsch.flexmark.parser.Parser;
+import com.vladsch.flexmark.parser.ParserEmulationProfile;
+import com.vladsch.flexmark.util.sequence.Escaping;
+import com.vladsch.flexmark.util.data.MutableDataSet;
+import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension;
+import com.vladsch.flexmark.ext.autolink.AutolinkExtension;
+
+buildscript {
+ repositories {
+mavenCentral()
+ }
+
+ dependencies {
+def flexmarkVersion = '0.61.24'
+
+classpath 'com.vladsch.flexmark:flexmark:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-autolink:' + flexmarkVersion
+classpath 'com.vladsch.flexmark:flexmark-ext-abbreviation:' +
flexmarkVersion
+ }
+}
+
+configure(subprojects.findAll { it.path == ':lucene' || it.path == ':solr' }) {
+ task markdownToHtml(type: Copy) {
+filteringCharset = 'UTF-8'
+includeEmptyDirs = false
+from('.') {// lucene
Review comment:
Right... same here.
##
File path: gradle/documentation/documentation.gradle
##
@@ -34,4 +36,11 @@ configure(subprojects.findAll { it.path == ':lucene' ||
it.path == ':solr' }) {
ext {
docroot = "${project.buildDir}/documentation"
}
+
+ task copy
[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=17097569#comment-17097569 ] Dawid Weiss commented on LUCENE-9321: - I this should be done this way: the task that collects final distribution would collect (sync or symlink; Windows may be a problem here) all documentation folders from all subprojects (this is easy: iterate over all java projects, get the outputDir of javadoc task) and create an index file that would point to all of them relative from this top-level. I do think javadoc outputs should be kept *with each project*. This is a convention and I don't think we should change it. The "flat" structure of javadocs is a distribution/ packaging matter and it should be handled there -- in the packaging/ distribution project/ task. I can help you with the details if you wish, Uwe. > 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 > Time Spent: 20m > 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-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097568#comment-17097568
]
ASF subversion and git services commented on SOLR-14440:
Commit 242f48a1cad43648283968a18d19756881af760b in lucene-solr's branch
refs/heads/master from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=242f48a ]
SOLR-14440 Cert Auth plugin
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097564#comment-17097564
]
ASF subversion and git services commented on SOLR-14440:
Commit a5c73d39d3f940b6fe5d4b21bee89fab65bce10a in lucene-solr's branch
refs/heads/master from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a5c73d3 ]
Revert "SOLR-14440 CertAuth plugin (#1463)"
Another commit accidentally snuck in
This reverts commit 7b289d6185f30b316d07d5ae5755cfc70c97921d.
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097562#comment-17097562
]
ASF subversion and git services commented on SOLR-14440:
Commit 3eb760a7d21fa072162da91e5dcc02d9c9d2511a in lucene-solr's branch
refs/heads/revert-1463-cert-auth from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3eb760a ]
Revert "SOLR-14440 Cert Auth plugin (#1463)"
This reverts commit 7b289d6185f30b316d07d5ae5755cfc70c97921d.
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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=17097551#comment-17097551 ] Uwe Schindler commented on LUCENE-9321: --- I cant proceed with the index.html/index.md template before I know where the javadocs finally land and how the directory stricture looks like. I have to iterate over all Java projects and collect the relative paths and the titles to generate the links in the main index file, so I am a bit stuck now. I am happy to implement this, but without javadocs in a central place I can't proceed. > 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 > Time Spent: 20m > 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=17097550#comment-17097550 ] Uwe Schindler commented on LUCENE-9321: --- Hi, yes please. Could you still have a look at the PR? At least the parts (copying assets and also converting markdown works). I added a template task to create the index file (it's handled by markdown.gradle because the intention is to use the static method in MarkdownFilter#convert(String) to generate the HTML from an in memory build Markdownfile as Input for the index file. > 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 > Time Spent: 20m > 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] (SOLR-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob reassigned SOLR-14440:
Assignee: Mike Drob
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097547#comment-17097547
]
ASF subversion and git services commented on SOLR-14440:
Commit 7b289d6185f30b316d07d5ae5755cfc70c97921d in lucene-solr's branch
refs/heads/master from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7b289d61 ]
SOLR-14440 Cert Auth plugin (#1463)
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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] (SOLR-14440) Provide Certificate Authentication Plugin
[
https://issues.apache.org/jira/browse/SOLR-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob resolved SOLR-14440.
--
Fix Version/s: master (9.0)
Resolution: Fixed
> Provide Certificate Authentication Plugin
> -
>
> Key: SOLR-14440
> URL: https://issues.apache.org/jira/browse/SOLR-14440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As described in [this
> comment|https://issues.apache.org/jira/browse/SOLR-4407?focusedCommentId=14308429&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14308429]
> on SOLR-4407, while we support Client SSL certificates we do not have a way
> to use them with authentication and authorization in an end-to-end fashion.
> Specifically, we don't have an easy (or any?) way to load the certificate
> subject via a user principal into the AuthorizationContext.
> The work in SOLR-10814 would also be good here, since the subject can have
> much more than just the CN, for example it can have locations and
> organizational units. {{C=US, ST=California, L=San Francisco, O=Wikimedia
> Foundation, Inc., CN=*.wikipedia.org}}
--
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] uschindler commented on pull request #1477: LUCENE-9321: Port markdown task to Gradle
uschindler commented on pull request #1477: URL: https://github.com/apache/lucene-solr/pull/1477#issuecomment-622489584 For now I have no idea how to handle the last task, so I left it as nocommit. @mocobeta: any ideas how to get the relative path and the title of all projects below lucene/solr? I am also not sure if the links hardcoded as absolute links in `render-javadoc.gradle` are consistent with the intended folder structure below `build/documentation`. These are all open questions and before a decission how to build the f*cking javadocs wthout copying all stuff to another folder (this costs imense amounts of disk space) I refuse to work on that issue/PR - sorry! @dweiss? 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_r418646100 ## File path: solr/bin/solr ## @@ -2097,6 +2097,14 @@ else SECURITY_MANAGER_OPTS=() fi +# Enable ADMIN UI by default, and give the option for users to disable it +if [ "$SOLR_ADMIN_UI_DISABLED" == "true" ]; then + SOLR_ADMIN_UI="-DdisableAdminUI=true" + echo -e "ADMIN UI Disabled" +else + SOLR_ADMIN_UI="-DdisableAdminUI=false" Review comment: Yes, that was an error on my part. I forgot to carry that over from the previous PR. I've added it. See line 2219 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] madrob commented on a change in pull request #1471: Revised SOLR-14014 PR Against Master
madrob commented on a change in pull request #1471: URL: https://github.com/apache/lucene-solr/pull/1471#discussion_r418644915 ## File path: solr/bin/solr ## @@ -2097,6 +2097,14 @@ else SECURITY_MANAGER_OPTS=() fi +# Enable ADMIN UI by default, and give the option for users to disable it +if [ "$SOLR_ADMIN_UI_DISABLED" == "true" ]; then + SOLR_ADMIN_UI="-DdisableAdminUI=true" + echo -e "ADMIN UI Disabled" +else + SOLR_ADMIN_UI="-DdisableAdminUI=false" Review comment: So if I set `SOLR_ADMIN_UI_DISABLED=true` in my `solr.in.sh`, then it sets `SOLR_ADMIN_UI="-DdisableAdminUI=true"` here, and then... does nothing? Because the `SOLR_ADMIN_UI` variable is never read. What am I missing? 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] madrob commented on a change in pull request #1467: LUCENE-9350: Don't hold references to large automata on FuzzyQuery
madrob commented on a change in pull request #1467:
URL: https://github.com/apache/lucene-solr/pull/1467#discussion_r418642710
##
File path: lucene/core/src/java/org/apache/lucene/search/FuzzyTermsEnum.java
##
@@ -88,43 +89,44 @@
* @throws IOException if there is a low-level IO error
*/
public FuzzyTermsEnum(Terms terms, Term term, int maxEdits, int
prefixLength, boolean transpositions) throws IOException {
-this(terms, term, stringToUTF32(term.text()), maxEdits, prefixLength,
transpositions);
- }
-
- private FuzzyTermsEnum(Terms terms, Term term, int[] codePoints, int
maxEdits, int prefixLength, boolean transpositions) throws IOException {
-this(terms, new AttributeSource(), term, codePoints.length, maxEdits,
-buildAutomata(term.text(), codePoints, prefixLength, transpositions,
maxEdits));
+this(terms, new AttributeSource(), term, () -> new
FuzzyAutomatonBuilder(term.text(), maxEdits, prefixLength, transpositions));
}
/**
* Constructor for enumeration of all terms from specified
reader which share a prefix of
* length prefixLength with term and which have at
most {@code maxEdits} edits.
*
- * After calling the constructor the enumeration is already pointing to the
first
- * valid term if such a term exists.
- *
+ * After calling the constructor the enumeration is already pointing to the
first
+ * valid term if such a term exists.
+ *
* @param terms Delivers terms.
- * @param atts {@link AttributeSource} created by the rewrite method of
{@link MultiTermQuery}
- * that contains information about competitive boosts during
rewrite
+ * @param atts An AttributeSource used to share automata between segments
* @param term Pattern term.
* @param maxEdits Maximum edit distance.
- * @param automata An array of levenshtein automata to match against terms,
- * see {@link #buildAutomata(String, int[], int, boolean,
int)}
+ * @param prefixLength the length of the required common prefix
+ * @param transpositions whether transpositions should count as a single edit
* @throws IOException if there is a low-level IO error
*/
- public FuzzyTermsEnum(Terms terms, AttributeSource atts, Term term, int
termLength,
- final int maxEdits, CompiledAutomaton[] automata) throws IOException {
+ FuzzyTermsEnum(Terms terms, AttributeSource atts, Term term, int maxEdits,
int prefixLength, boolean transpositions) throws IOException {
+this(terms, atts, term, () -> new FuzzyAutomatonBuilder(term.text(),
maxEdits, prefixLength, transpositions));
+ }
+
+ private FuzzyTermsEnum(Terms terms, AttributeSource atts, Term term,
Supplier automatonBuilder) throws IOException {
-this.maxEdits = maxEdits;
this.terms = terms;
-this.term = term;
this.atts = atts;
-this.termLength = termLength;
+this.term = term;
this.maxBoostAtt =
atts.addAttribute(MaxNonCompetitiveBoostAttribute.class);
this.boostAtt = atts.addAttribute(BoostAttribute.class);
-this.automata = automata;
+atts.addAttributeImpl(new AutomatonAttributeImpl());
Review comment:
@uschindler
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] (SOLR-10415) Within solr-core, debug/trace level logging should use parameterized log messages
[
https://issues.apache.org/jira/browse/SOLR-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-10415.
---
Fix Version/s: 8.6
Resolution: Fixed
All the logging calls are either
1> parameterized
or
2> surrounded with "if (log.is*Enabled)" clauses and a validation check has
been added to master/9x in Gradle.
> Within solr-core, debug/trace level logging should use parameterized log
> messages
> -
>
> Key: SOLR-10415
> URL: https://issues.apache.org/jira/browse/SOLR-10415
> Project: Solr
> Issue Type: Improvement
> Components: logging
>Reporter: Michael Braun
>Priority: Trivial
> Fix For: 8.6
>
>
> Noticed in several samplings of an active Solr that several debug statements
> were taking decently measurable time because of the time of the .toString
> even when the log.debug() statement would not output because it was
> effectively INFO or higher. Using parameterized logging statements, ie
> 'log.debug("Blah {}", o)' will avoid incurring that cost.
--
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-14430) Authorization plugins should check roles from request
[
https://issues.apache.org/jira/browse/SOLR-14430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097524#comment-17097524
]
Mike Drob commented on SOLR-14430:
--
I think that's definitely movement in the right direction. I'd like to reuse as
much of the servlet spec as we can without creating our own way of handling it
since I believe it will be less surprising for the next dev to come along, and
might make it easier for them to integrate with frameworks that are relatively
standards conforming. After your changes, it seems like {{isUserInRole}} would
be easy to implement by delegating to
{{getVerifiedRoles().contains(getUserPrincipal().getName())}}. Happy to see
that as part of the other patch, or we can address it here as follow on, no
real preference.
> Authorization plugins should check roles from request
> -
>
> Key: SOLR-14430
> URL: https://issues.apache.org/jira/browse/SOLR-14430
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mike Drob
>Priority: Major
>
> The AuthorizationContext exposes {{getUserPrincipal}} to the plugin, but it
> does not allow the plugin to interrogate the request for {{isUserInRole}}. If
> we trust the request enough to get a principal from it, then we should trust
> it enough to ask about roles, as those could have been defined and verified
> by an authentication plugin.
> This model would be an alternative to the current model where
> RuleBasedAuthorizationPlugin maintains its own user->role mapping.
--
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] (SOLR-11884) find/fix inefficiencies in our use of logging
[
https://issues.apache.org/jira/browse/SOLR-11884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-11884.
---
Fix Version/s: 7.4
Resolution: Fixed
The specific problem with %C was fixed in Solr 7.4. Other concerns are fixed in
other JIRAs, most notably LUCENE07788
> find/fix inefficiencies in our use of logging
> -
>
> Key: SOLR-11884
> URL: https://issues.apache.org/jira/browse/SOLR-11884
> Project: Solr
> Issue Type: Improvement
> Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
>
> We've been looking at Solr using Flight Recorder and ran across some
> interesting things I'd like to discuss. Let's discuss general logging
> approaches here, then perhaps break out sub-JIRAs when we reach any kind of
> agreement.
> 1> Every log message generates a new Throwable, presumably to get things like
> line number, file, class name and the like. On a 2 minute run blasting
> updates this meant 150,000 (yes, 150K) instances of "new Throwable()".
>
> See the section "Asynchronous Logging with Caller Location Information" at:
> [https://logging.apache.org/log4j/2.x/performance.html]
> I'm not totally sure changing the layout pattern will fix this in log4j 1.x,
> but apparently certainly should in log4j 2.
>
> The cost of course would be that lots of our log messages would lack some of
> the information. Exceptions would still contain all the file/class/line
> information of course.
>
> Proposal:
> Change the layout pattern to, by default, _NOT_ include information that
> requires a Throwable to be created. Also include a pattern that could be
> un-commented to get this information back for troubleshooting.
>
>
>
> We generate strings when we don't need them. Any construct like
> log.info("whatever " + method_that_builds_a_string + " : " + some_variable);
> generates the string (some of which are quite expensive) and then throws it
> away if the log level is at, say, WARN. The above link also shows that
> parameterizing this doesn't suffer this problem, so anything like the above
> should be re-written as:
> log.info("whatever {} : {} ", method_that_builds_a_string, some_variable);
>
> The alternative is to do something like but let's make use of the built-in
> capabilities instead.
> if (log.level >= INFO) {
> log.info("whatever " + method_that_builds_a_string + " : " +
> some_variable);
> }
> etc.
> This would be a pretty huge thing to fix all-at-once so I suppose we'll have
> to approach it incrementally. It's also something that, if we get them all
> out of the code should be added to precommit failures. In the meantime, if
> anyone who has the precommit chops could create a target that checked for
> this it'd be a great help in tracking all of them down, then could be
> incorporated in the regular precommit checks if/when they're all removed.
> Proposal:
> Use JFR or whatever to identify the egregious violations of this kind of
> thing (I have a couple I've found) and change them to parameterized form (and
> prove it works). Then see what we can do to move forward with removing them
> all through the code base.
>
>
--
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-7788) fail precommit on unparameterised log messages and examine for wasted work/objects
[ https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-7788. Fix Version/s: 8.6 Resolution: Fixed These checks are now wired in to gradle, both precommit and check. I did _NOT_ port all of the checks to the Ant build, so there's no equivalent checks in 8x. That said, I did make all the changes to logging calls in both 8.6 and master. > fail precommit on unparameterised log messages and examine for wasted > work/objects > -- > > Key: LUCENE-7788 > URL: https://issues.apache.org/jira/browse/LUCENE-7788 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.6 > > Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch, > gradle_only.patch > > Time Spent: 50m > Remaining Estimate: 0h > > SOLR-10415 would be removing existing unparameterised log.trace messages use > and once that is in place then this ticket's one-line change would be for > 'ant precommit' to reject any future unparameterised log.trace message use. -- 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] madrob commented on a change in pull request #341: SOLR-12131: ExternalRoleRuleBasedAuthorizationPlugin
madrob commented on a change in pull request #341:
URL: https://github.com/apache/lucene-solr/pull/341#discussion_r418632788
##
File path:
solr/core/src/java/org/apache/solr/security/PrincipalWithUserRoles.java
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.security;
+
+import java.io.Serializable;
+import java.security.Principal;
+import java.util.Set;
+
+import org.apache.http.util.Args;
+
+/**
+ * Type of Principal object that can contain also a list of roles the user has.
+ * One use case can be to keep track of user-role mappings in an Identity
Server
+ * external to Solr and pass the information to Solr in a signed JWT token or
in
+ * another secure manner. The role information can then be used to authorize
+ * requests without the need to maintain or lookup what roles each user
belongs to.
+ */
+public class PrincipalWithUserRoles implements Principal, VerifiedUserRoles,
Serializable {
Review comment:
Could this class be `final`? Also, why Serializable?
##
File path: solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc
##
@@ -64,6 +66,34 @@ There are several things defined in this example:
<5> The 'admin' role has been defined, and it has permission to edit security
settings.
<6> The 'solr' user has been defined to the 'admin' role.
+=== Example for ExternalRoleRuleBasedAuthorizationPlugin
+This example `security.json` shows how an imagined `JWTAuthPlugin`, which
pulls user and user roles from JWT claims, can work with the
`ExternalRoleRuleBasedAuthorizationPlugin` plugin:
Review comment:
s/imagined//, this exists, right?
##
File path:
solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPluginBase.java
##
@@ -0,0 +1,270 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+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.Arrays;
+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.CommandOperation;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.common.util.ValidatingJsonMap;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+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;
+
+/**
+ * Base class for rule based authorization plugins
+ */
+public abstract class RuleBasedAuthorizationPluginBase implements
AuthorizationPlugin, ConfigEditablePlugin, SpecProvider {
Review comment:
Is this largely a copy of the old RuleBasedAuthorizationPlugin? If you
can let me know which parts were changed, it will be easier to review.
##
File path:
solr/core/src/java/org/apache/solr/security/PrincipalWithUserRoles.java
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under th
[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log messages and examine for wasted work/objects
[ https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097518#comment-17097518 ] ASF subversion and git services commented on LUCENE-7788: - Commit 7388a81d7a4f5af4eafb4f7c3b5c27f3a3939567 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7388a81 ] LUCENE-7788: fail precommit on unparameterised log messages and examine for wasted work/objects > fail precommit on unparameterised log messages and examine for wasted > work/objects > -- > > Key: LUCENE-7788 > URL: https://issues.apache.org/jira/browse/LUCENE-7788 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Erick Erickson >Priority: Minor > Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch, > gradle_only.patch > > Time Spent: 50m > Remaining Estimate: 0h > > SOLR-10415 would be removing existing unparameterised log.trace messages use > and once that is in place then this ticket's one-line change would be for > 'ant precommit' to reject any future unparameterised log.trace message use. -- 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-7788) fail precommit on unparameterised log messages and examine for wasted work/objects
[ https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097517#comment-17097517 ] ASF subversion and git services commented on LUCENE-7788: - Commit 217c2faa2cd7b540d8e9933355dbd878a4d32057 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=217c2fa ] LUCENE-7788: fail precommit on unparameterised log messages and examine for wasted work/objects > fail precommit on unparameterised log messages and examine for wasted > work/objects > -- > > Key: LUCENE-7788 > URL: https://issues.apache.org/jira/browse/LUCENE-7788 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Erick Erickson >Priority: Minor > Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch, > gradle_only.patch > > Time Spent: 50m > Remaining Estimate: 0h > > SOLR-10415 would be removing existing unparameterised log.trace messages use > and once that is in place then this ticket's one-line change would be for > 'ant precommit' to reject any future unparameterised log.trace message use. -- 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=17097513#comment-17097513 ] Tomoko Uchida commented on LUCENE-9321: --- I left a comment about javadocs destination folder on LUCENE-9278 before seeing the comments here. Would we need more discussions about where the outputs of "renderJavadoc" task should go, if we still don't get a consensus about it ? > 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 > Time Spent: 10m > 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-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097507#comment-17097507 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13289: -- bq. It seems to me what we want to convey is whether the count is exact, or an approximation. Are there any other "relations" that can be returned here? I think that's it, so if instead we were to use a boolean That was my initial thought too. See [#comment-17094032]. I could be convinced to go back to boolean if we think we don't need the relation. My biggest concern were options that could be added in Lucene that would be impossible to represent with a Boolean. I guess in that case, if it happens we can go back and do another API change then. Regardless of what term we use (numFoundPrecision seems to be the most popular). I plan to commit this soon (probably early next week) unless there are any concerns. > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- 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] madrob commented on a change in pull request #1470: SOLR-14354: Async or using threads in better way for HttpShardHandler
madrob commented on a change in pull request #1470:
URL: https://github.com/apache/lucene-solr/pull/1470#discussion_r418628204
##
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:
Use `@SolrSingleThreaded`
##
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:
And clear the map?
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_r418630121 ## File path: solr/bin/solr ## @@ -2097,6 +2097,14 @@ else SECURITY_MANAGER_OPTS=() fi +# Enable ADMIN UI by default, and give the option for users to disable it +if [ "$SOLR_ADMIN_UI_DISABLED" == "true" ]; then + SOLR_ADMIN_UI="-DdisableAdminUI=true" + echo -e "ADMIN UI Disabled" +else + SOLR_ADMIN_UI="-DdisableAdminUI=false" Review comment: You have to explicitly pass it, or you can pass the system property 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_r418629568 ## File path: solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java ## @@ -15,6 +15,13 @@ * limitations under the License. */ package org.apache.solr.servlet; +import javax.servlet.http.HttpServletRequest; Review comment: Yes. I did that because the precommit failed before locally. 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] madrob commented on a change in pull request #1470: SOLR-14354: Async or using threads in better way for HttpShardHandler
madrob commented on a change in pull request #1470:
URL: https://github.com/apache/lucene-solr/pull/1470#discussion_r418627559
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java
##
@@ -66,4 +80,132 @@ public LBHttp2SolrClient(Http2SolrClient httpClient,
String... baseSolrUrls) {
protected SolrClient getClient(String baseUrl) {
return httpClient;
}
+
+ public interface OnComplete {
Review comment:
Yea, having a generic interface sounds good.
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] madrob commented on a change in pull request #1471: Revised SOLR-14014 PR Against Master
madrob commented on a change in pull request #1471:
URL: https://github.com/apache/lucene-solr/pull/1471#discussion_r418622731
##
File path: solr/bin/solr.cmd
##
@@ -1288,6 +1295,7 @@ REM '-OmitStackTraceInFastThrow' ensures stack traces in
errors,
REM users who don't care about useful error msgs can override in SOLR_OPTS
with +OmitStackTraceInFastThrow
set "START_OPTS=%START_OPTS% -XX:-OmitStackTraceInFastThrow"
set START_OPTS=%START_OPTS% !GC_TUNE! %GC_LOG_OPTS%
+set START_OPTS=-DdisableAdminUI=%DISABLE_ADMIN_UI%
Review comment:
This clobbers the previous START_OPTS
##
File path: solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java
##
@@ -15,6 +15,13 @@
* limitations under the License.
*/
package org.apache.solr.servlet;
+import javax.servlet.http.HttpServletRequest;
Review comment:
nit: did you mean to move these imports around?
##
File path: solr/bin/solr
##
@@ -2097,6 +2097,14 @@ else
SECURITY_MANAGER_OPTS=()
fi
+# Enable ADMIN UI by default, and give the option for users to disable it
+if [ "$SOLR_ADMIN_UI_DISABLED" == "true" ]; then
+ SOLR_ADMIN_UI="-DdisableAdminUI=true"
+ echo -e "ADMIN UI Disabled"
+else
+ SOLR_ADMIN_UI="-DdisableAdminUI=false"
Review comment:
It doesn't look like this property is ever passed to the run command?
##
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:
Would this make sense to do before the close shield methods?
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] (SOLR-14452) "classloading deadlock" issue with DocSet/SortedIntDocSet
[
https://issues.apache.org/jira/browse/SOLR-14452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter resolved SOLR-14452.
---
Resolution: Invalid
Gah, yes -- i initially found this on a PR branch and ment to double check it
was reproducible on master before submitting but it slipped my mind.
sorry for noise.
> "classloading deadlock" issue with DocSet/SortedIntDocSet
> -
>
> Key: SOLR-14452
> URL: https://issues.apache.org/jira/browse/SOLR-14452
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> While beasting some facet related cloud tests on master, I noticed a pattern
> of occasional failures that seemed to crop up...
> * test ultimately fails due to a time out (usually the client threads time
> out waiting for a server response)
> * if i notice my CPU isn't spinning very hard _before_ the test fails, I can
> capture a jstack and inspect some threads
> * there will be multiple jetty/solr request threads (ex:
> {{"qtp82184175-145"}} whose stack traces show various stages of DocSet
> collection that show they are {{"... in Object.wait()"}} but also {{RUNNABLE}}
> ...this isn't a thread summary+state combination that i'm use to seeing when
> looking at thread dumps, and some research into when/why this might happen
> lead me to:
> *
> [https://stackoverflow.com/questions/28631656/runnable-thread-state-but-in-object-wait]
> ** [https://stackoverflow.com/a/28776438/689372]
> ***
>
> [http://ternarysearch.blogspot.com/2013/07/static-initialization-deadlock.html]
> [https://bugs.openjdk.java.net/browse/JDK-8037567]
> ...while the comments/status of JDK-8037567 suggests "nothing wrong here" the
> overall symptoms/description of the problem in the SO answer and linked blog
> and summation that this is essentially a "deadlock" situation in the class
> loader, do seem to correlate to some of the specifics I can see in the stack
> traces when this happens while running solr tests...
> * at least one "RUNNABLE / Object.wait" thread trying to do class init;
> class: DocSet...
> {noformat}
> "qtp1535326437-68" #68 prio=5 os_prio=0 cpu=72.48ms elapsed=241.69s
> tid=0x7fc08c0a4000 nid=0x864 in Object.wait() [0x7fc0adedd000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.solr.search.DocSet.(DocSet.java:118)
> at
> org.apache.solr.search.DocSetCollector.getDocSet(DocSetCollector.java:90) //
> "new BitDocSet(..)"
> at org.apache.solr.search.DocSetUtil.getDocSet(DocSetUtil.java:93)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1730)
> {noformat}
> * other "RUNNABLE / Object.wait" threads are on lines that involve
> instantiating a subclass of DocSet:
> **
> {noformat}
> "qtp1535326437-67" #67 prio=5 os_prio=0 cpu=801.44ms elapsed=241.69s
> tid=0x7fc08c0a1800 nid=0x863 in Object.wait() [0x7fc0adfdf000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.solr.search.DocSetCollector.getDocSet(DocSetCollector.java:90) //
> "new BitDocSet(..)"
> at org.apache.solr.search.DocSetUtil.getDocSet(DocSetUtil.java:93)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1730)
> {noformat}
> **
> {noformat}
> "qtp82184175-65" #65 prio=5 os_prio=0 cpu=137.76ms elapsed=241.69s
> tid=0x7fc088092000 nid=0x860 in Object.wait() [0x7fc0ae2e2000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.solr.search.DocSetCollector.getDocSet(DocSetCollector.java:84) //
> "new SortedIntDocSet(..)"
> at org.apache.solr.search.DocSetUtil.getDocSet(DocSetUtil.java:93)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1730)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
> {noformat}
> ** etc...
> * DocSet has a static reference to a concrete subclass...
> ** {{public static final DocSet EMPTY = new SortedIntDocSet(new int[0], 0);
>
> I should point out:
> * While this particular "class loading deadlock" issue seems more likely to
> happen in a "test" situation where the JVMs/classloaders are short lived,
> there's no reason to assume this type of failure couldn't happen in a
> production solr instance when handling a burst of queries right after startup.
> * This type of failure (either specifically due to "DocSet vs
> SortedIntDocSet", or due to similar patterns in other classes) may also be
> the root cause of various other hard to reproduce "timed out" test failures
> we've seen over the years.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097491#comment-17097491 ] Tomoko Uchida commented on LUCENE-9278: --- Thank you for fixing it. I tested the task on Linux/MacOS and Windows, but none of them had paths with whitespaces. About Javadoc output directory there were discussions before: https://issues.apache.org/jira/browse/LUCENE-9201?focusedCommentId=17034121&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17034121 For now I am inclined to [~dweiss]'s view about task design (separation between "building" and "publishing" phases), though I understand that it could be a bit controversial. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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=17097488#comment-17097488 ] Uwe Schindler commented on LUCENE-9321: --- I started with markdown and copying of static assets. The index.html stuff is just a nocommit. My problem is that the javadocs are splattered around and not yet copied to the central "build/documentation" folder. Any ideas [~tomoko]? Here is the first PR, just push any suggestions to it, it's still WIP: https://github.com/apache/lucene-solr/pull/1477 > 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 > Time Spent: 10m > 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
[GitHub] [lucene-solr] uschindler opened a new pull request #1477: LUCENE-9321: Port markdown task to Gradle
uschindler opened a new pull request #1477: URL: https://github.com/apache/lucene-solr/pull/1477 This PR handles the markdown specific parts of the Lucene/Solr documentation: - copy static assets (unfortunetely those are not yet unified between borth projects) - convert .md files to HTML using flexmark - create the index files by first iterating through the projects and collecting all links, creating a markdown representation of all links locally and then write as index.html to docus folder 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-9278. --- Resolution: Fixed I merged the change. When running "gradle javadoc" my problem is now that the resulting Javadocs are NOT in the root's documentation folder. Are you intending to copy all files into that folder afterwards - which is a desaster. Why not change this task to NOT use the default Gradle output folder and instead write Javadocs to where they belong? The "gradle documentation" task recently added adds a "project.docroot" folder, why not use that also as final location for javadocs? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097463#comment-17097463 ] ASF subversion and git services commented on LUCENE-9278: - Commit 26b0b54bd3740a43775fc3b6af5d02c70d6e3283 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=26b0b54 ] LUCENE-9278: Fix javadocs task to work on windows and with whitespace in project folder (#1476) > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097456#comment-17097456 ] Uwe Schindler commented on LUCENE-9278: --- Here is the PR, I will commit it in a moment, because I want to proceed working on the Markdown stuff. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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
