[PR] chore(deps): update dependency io.github.oshai:kotlin-logging to v7.0.4 [solr]
solrbot opened a new pull request, #3169:
URL: https://github.com/apache/solr/pull/3169
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[io.github.oshai:kotlin-logging](https://redirect.github.com/oshai/kotlin-logging)
| dependencies | patch | `7.0.3` -> `7.0.4` |
---
### Release Notes
oshai/kotlin-logging (io.github.oshai:kotlin-logging)
###
[`v7.0.4`](https://redirect.github.com/oshai/kotlin-logging/releases/tag/7.0.4)
[Compare
Source](https://redirect.github.com/oshai/kotlin-logging/compare/7.0.3...7.0.4)
What's Changed
- Bump org.jetbrains.dokka from 1.9.20 to 2.0.0 by
[@dependabot](https://redirect.github.com/dependabot) in
[https://github.com/oshai/kotlin-logging/pull/464](https://redirect.github.com/oshai/kotlin-logging/pull/464)
- Bump com.diffplug.spotless from 6.25.0 to 7.0.1 by
[@dependabot](https://redirect.github.com/dependabot) in
[https://github.com/oshai/kotlin-logging/pull/467](https://redirect.github.com/oshai/kotlin-logging/pull/467)
- Bump actions/cache from 4.1.2 to 4.2.0 by
[@dependabot](https://redirect.github.com/dependabot) in
[https://github.com/oshai/kotlin-logging/pull/461](https://redirect.github.com/oshai/kotlin-logging/pull/461)
- Update gradle to 8.12 by
[@oshai](https://redirect.github.com/oshai) in
[https://github.com/oshai/kotlin-logging/pull/469](https://redirect.github.com/oshai/kotlin-logging/pull/469)
- Bump com.android.library from 8.6.1 to 8.8.0 by
[@dependabot](https://redirect.github.com/dependabot) in
[https://github.com/oshai/kotlin-logging/pull/468](https://redirect.github.com/oshai/kotlin-logging/pull/468)
- Changes needed for compiler plugin by
[@neeme-praks-sympower](https://redirect.github.com/neeme-praks-sympower)
in
[https://github.com/oshai/kotlin-logging/pull/474](https://redirect.github.com/oshai/kotlin-logging/pull/474)
**Full Changelog**:
https://github.com/oshai/kotlin-logging/compare/7.0.3...7.0.4
---
### Configuration
📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time
(no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are
satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry
checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] If you want to rebase/retry this PR, check this
box
---
This PR has been generated by [Renovate
Bot](https://redirect.github.com/solrbot/renovate-github-action)
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
dsmiley commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947894348
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
Agree. Of course there needs to be some test of this specific change being
added. Just one unit test is fine. If that seems lacking, remember that the
totality of Solr tests will also be running with this by default, and thus if
there's an incompatibility we'll probably see it.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
dsmiley commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947899623
##
solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:
##
@@ -863,6 +871,21 @@ protected Map readMap(DataInputInputStream
dis, int sz) throws I
return m;
}
+ @SuppressWarnings({"rawtypes", "unchecked"})
+ protected Map
readMapAsSimpleOrderedMapForStringKeys(DataInputInputStream dis, int sz)
+ throws IOException {
+
+SimpleOrderedMap entries = new SimpleOrderedMap<>(sz);
+
+for (int i = 0; i < sz; i++) {
+ Object key = readVal(dis);
+ assert key instanceof String;
+ Object val = readVal(dis);
+ entries.put((String) key, val);
Review Comment:
That was an `O(N^2)` performance bug, by the way 😱
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
dsmiley commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947895092
##
solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:
##
@@ -863,6 +871,21 @@ protected Map readMap(DataInputInputStream
dis, int sz) throws I
return m;
}
+ @SuppressWarnings({"rawtypes", "unchecked"})
+ protected Map
readMapAsSimpleOrderedMapForStringKeys(DataInputInputStream dis, int sz)
+ throws IOException {
+
+SimpleOrderedMap entries = new SimpleOrderedMap<>(sz);
+
+for (int i = 0; i < sz; i++) {
+ Object key = readVal(dis);
+ assert key instanceof String;
+ Object val = readVal(dis);
+ entries.put((String) key, val);
Review Comment:
```suggestion
entries.add((String) key, val); // using NL.add() since key won't
repeat
```
##
solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:
##
@@ -1436,4 +1459,8 @@ public void close() throws IOException {
daos.flushBuffer();
}
}
+
Review Comment:
TODO javadocs.
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -409,12 +419,17 @@ private static byte[] getBytes(Object o, boolean
readAsCharSeq) throws IOExcepti
}
}
- private static Object getObject(byte[] bytes) throws IOException {
+ private static Object getObject(byte[] bytes, boolean mapAsNamedList) throws
IOException {
Review Comment:
don't need these getObject anymore, I think
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17648) multiThreaded: Remove obsolete RejectedExecutionException avoidance
[ https://issues.apache.org/jira/browse/SOLR-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925303#comment-17925303 ] ASF subversion and git services commented on SOLR-17648: Commit 021541af199ab09ce604adae2095efe5cf0f77d3 in solr's branch refs/heads/branch_9x from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=021541af199 ] SOLR-17648: multiThreaded=true: changed queue implementation (#3155) from unlimited to 1000 max, after which the caller thread will execute. Didn't need the RejectedExecutionException avoidance hack anymore; Lucene 9.12 has it. Configurable size: solr.search.multiThreaded.queueSize (cherry picked from commit 861a7761707457a65a3736ecc274cff3c8cb56e5) > multiThreaded: Remove obsolete RejectedExecutionException avoidance > --- > > Key: SOLR-17648 > URL: https://issues.apache.org/jira/browse/SOLR-17648 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Lucene 9.12 fixed a RejectedExecutionException risk > https://github.com/apache/lucene/pull/13622 in which > RejectedExecutionException is caught and the task is run. This is done with a > simple Executor wrapper in IndexSearcher's constructor. I propose we remove > the hack/work-around in SolrIndexSearcher. This brings back a > LinkedBlockingQueue, and queue size to determine. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17648) multiThreaded: Remove obsolete RejectedExecutionException avoidance
[ https://issues.apache.org/jira/browse/SOLR-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-17648. - Fix Version/s: 9.9 Resolution: Fixed > multiThreaded: Remove obsolete RejectedExecutionException avoidance > --- > > Key: SOLR-17648 > URL: https://issues.apache.org/jira/browse/SOLR-17648 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Lucene 9.12 fixed a RejectedExecutionException risk > https://github.com/apache/lucene/pull/13622 in which > RejectedExecutionException is caught and the task is run. This is done with a > simple Executor wrapper in IndexSearcher's constructor. I propose we remove > the hack/work-around in SolrIndexSearcher. This brings back a > LinkedBlockingQueue, and queue size to determine. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947903626
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
@dsmiley
We have now 9 failing test, here my findings:
TestFastJavabinDecoder
testSimple-> the assert on line 136 fails due to the JSON with a SOM in it
has some extra line breaks
TestUpdateRequestCodec
testBackCompat4_5() -> failing because /solrj/updateReq_4_5.bin" has a Map
with SolrInputDocument as Key
testStreamableInputDocFormat -> because in
JavaBinUpdateRequestCodec.StreamingCodec#readOuterMostDocIterator line 315
instanceOf NamedList is now true, and it is checked before instanceof Map
ClusterStateProviderTest
6 tests are failing e.g. testClusterStateProvider -> ClusterState is using
org.apache.solr.common.util.Utils to deserialize the Json, which creates a
LinkedHashMap and clusterStateHttp has now a SOM in it
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947903626
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
@dsmiley
We have now 9 failing test, here my findings:
TestFastJavabinDecoder
testSimple-> the assert on line 136 fails due to the JSON with a SOM in it
has some extra line breaks
TestUpdateRequestCodec
testBackCompat4_5() -> failing because /solrj/updateReq_4_5.bin" has a Map
with SolrInputDocument as Key
testStreamableInputDocFormat -> because in
JavaBinUpdateRequestCodec.StreamingCodec#readOuterMostDocIterator line 315
instanceOf NamedList is now true, and it is checked before instanceof Map
ClusterStateProviderTest
6 tests are failing e.g. testClusterStateProvider -> assertThat on line
262 fails. ClusterState is using org.apache.solr.common.util.Utils to
deserialize the Json, which creates a LinkedHashMap and clusterStateHttp has
now a SOM in it
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947903626
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
@dsmiley
We have now 9 failing tests, here my findings:
TestFastJavabinDecoder
testSimple-> the assert on line 136 fails due to the JSON with a SOM in it
has some extra line breaks
TestUpdateRequestCodec
testBackCompat4_5() -> failing because /solrj/updateReq_4_5.bin" has a Map
with SolrInputDocument as Key
testStreamableInputDocFormat -> because in
JavaBinUpdateRequestCodec.StreamingCodec#readOuterMostDocIterator line 315
instanceOf NamedList is now true, and it is checked before instanceof Map
ClusterStateProviderTest
6 tests are failing e.g. testClusterStateProvider -> assertThat on line
262 fails. ClusterState is using org.apache.solr.common.util.Utils to
deserialize the Json, which creates a LinkedHashMap and clusterStateHttp has
now a SOM in it
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
dsmiley commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947912403
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
TestUpdateRequestCodec: dunno what to make of that without debugging;
hopefully you can make recommendations. Not surprised to see this _kind of
issue_ where some code is doing instanceof checks in a certain order, written
at a time when no NamedList was a Map but now a prominent (and even most
popular, I'd say) is actually one. You might want to search the codebase for
instanceof checks against NamedList to see if there are other areas to improve.
I have some WIP for Utils.java
ClusterStateProviderTest: looks like just needs to convert both maps to the
same type (e.g. wrap in HashMap) ?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947912506
##
solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:
##
@@ -863,6 +871,21 @@ protected Map readMap(DataInputInputStream
dis, int sz) throws I
return m;
}
+ @SuppressWarnings({"rawtypes", "unchecked"})
+ protected Map
readMapAsSimpleOrderedMapForStringKeys(DataInputInputStream dis, int sz)
+ throws IOException {
+
+SimpleOrderedMap entries = new SimpleOrderedMap<>(sz);
+
+for (int i = 0; i < sz; i++) {
+ Object key = readVal(dis);
+ assert key instanceof String;
+ Object val = readVal(dis);
+ entries.put((String) key, val);
Review Comment:
oh, I am glad at least one of us knows what we are doing here;)
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
dsmiley commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947924419
##
solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:
##
@@ -863,6 +871,21 @@ protected Map readMap(DataInputInputStream
dis, int sz) throws I
return m;
}
+ @SuppressWarnings({"rawtypes", "unchecked"})
+ protected Map
readMapAsSimpleOrderedMapForStringKeys(DataInputInputStream dis, int sz)
+ throws IOException {
+
+SimpleOrderedMap entries = new SimpleOrderedMap<>(sz);
+
+for (int i = 0; i < sz; i++) {
+ Object key = readVal(dis);
+ assert key instanceof String;
+ Object val = readVal(dis);
+ entries.put((String) key, val);
Review Comment:
It underscores my concern about making SimpleOrderedMap mutable. I still
question it.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17659: Issue Type: New Feature (was: Improvement) > Implement basic authentication in Admin UI > -- > > Key: SOLR-17659 > URL: https://issues.apache.org/jira/browse/SOLR-17659 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > In the new UI one of the key features that is not implemented yet is user > authentication. In order to secure and securily access Solr, the user should > be able to authenticate against a Solr instance with basic credentials. > h2. Task > Implement basic user authentication (with credentials) according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1]. > h2. Acceptance Criteria > - The user can access a Solr instance that has user authentication enabled > - The user can at least authenticate with credentials (basic auth) > - The credentials form is displayed after the user has established a > connection with a Solr instance, that is, after a Solr instance was found > - The user can return to the start screen where the Solr URL was provided, if > he decides to abort the authentication step > - The user is no longer redirected to the dashboard or any other screen if > user authentication is required > - The credentials are used for any subsequent request > h2. Additional Information > The support for additional authentication options does not have to be > addressed in this issue. If it proves to be straight-forward, feel free to > implement additional auth options as well. > The credentials do not have to survive an application restart (desktop). > Storing credentials securely will be addressed in a separate issue. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17658) Implement Admin UI Start Screen
[ https://issues.apache.org/jira/browse/SOLR-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17658: Issue Type: New Feature (was: Improvement) > Implement Admin UI Start Screen > --- > > Key: SOLR-17658 > URL: https://issues.apache.org/jira/browse/SOLR-17658 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > The new UI is built for web (shipped with Solr server and webapp) and desktop > (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the > API. In order to have an option to allow the user to select the Solr instance > (URL), a start screen was designed that should be displayed as initial screen > / entrypoint. > h2. Task > Implement the start screen according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. > Only the first form where the user can provide a Solr URL is relevant for > this ticket. > h2. Acceptance Criteria > - When the user opens for the first time the new UI, the start screen is > displayed > - On desktop, the user can edit the Solr URL and provide a custom URL > - A placeholder to http://localhost:8983 is used on desktop as default value > for the Solr URL > - If the user is on web and accessed the Solr instance via a Solr URL, the > host from the current URL is used and the user is automatically connected > - When successfully connected, the user is redirected to the Dashboard (or > any existing screen for now) > - The provided Solr URL is used in the HTTP client > - The logout button redirects the user back to the start screen > - A warning dialog is shown before connecting to an HTTP URL (see designs) > h2. Additional Information > You should avoid handling authentication / authorization in this issue, as > this is addressed in a separate issue. The designs cover an authentication > form, but that can be ignored for now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17657) Evaluate and Update checksum and signature verification
[
https://issues.apache.org/jira/browse/SOLR-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christos Malliaridis updated SOLR-17657:
Description:
Dependency verification is an important step that is used when we want to
verify the integrity of third-party libraries. Right now, we have custom gradle
tasks for generating and verifying the gradle checksums.
These custom gradle tasks seem to be limited in their dependency resolution and
do not check dependencies from plugins, buildSrc or integrated builds.
Gradle comes with dependency verification options that also support signature
checks, whereever available. It is also capable of taking plugins and
configurations from buildSrc and integrated builds into account. See [Gradle
dependency
verification|https://docs.gradle.org/current/userguide/dependency_verification.html]
for more information.
h2. Task
Evaluate the output and the capabilities available of the Gradle-native
features from the above link and update the gradle tasks and development flows
if they are preferred.
You can use the gradle task
{{.\gradlew \-\-write-verification-metadata sha256 help}}
for generating your first output at {{gradle/verification-metadata.xml}}.
h2. Acceptance Criteria
- The GitHub workflows continue verifying checksums and optionally signatures
If updated to the Gradle-native tasks:
- The steps in our developer guide are updated accordingly
- redundant custom gradle tasks related to the checksum generation and
verification are removed
- Checksum files from {{solr/licenses}} are removed
If not upated to Gradle-native tasks:
- The existing tasks are updated so that checksums from the new UI module
(Kotlin multiplatform module) are also generated
h2. Additional Information
The new UI module introduced in #2605 is a Kotlin multiplatform module, which
does not use the JavaPlugin that is used for resolving jar information (see
jarValidation task). This means that it is not covered by our custom tasks.
We should try to address this issue before Solr 10 is released, because we have
already changed a lot of things related to dependency management.
was:
Dependency verification is an important step that is used when we want to
verify the integrity of third-party libraries. Right now, we have custom gradle
tasks for generating and verifying the gradle checksums.
These custom gradle tasks seem to be limited in their dependency resolution and
do not check dependencies from plugins, buildSrc or integrated builds.
Gradle comes with dependency verification options that also support signature
checks, whereever available. It is also capable of taking plugins and
configurations from buildSrc and integrated builds into account. See [Gradle
dependency
verification|https://docs.gradle.org/current/userguide/dependency_verification.html]
for more information.
h2. Task
Evaluate the output and the capabilities available of the Gradle-native
features from the above link and update the gradle tasks and development flows
if they are preferred.
You can use the gradle task
{{.\gradlew \-\-write-verification-metadata sha256 help}}
for generating your first output at {{gradle/verification-metadata.xml}}.
h2. Acceptance Criteria
- The GitHub workflows continue verifying checksums and optionally signatures
If updated to the Gradle-native tasks:
- The steps in our developer guide are updated accordingly
- redundant custom gradle tasks related to the checksum generation and
verification are removed
- Checksum files from {{solr/licenses}} are removed
h2. Additional Information
The new UI module introduced in #2605 is a Kotlin multiplatform module, which
does not use the JavaPlugin that is used for resolving jar information (see
jarValidation task). This means that it is not covered by our custom tasks.
We should try to address this issue before Solr 10 is released, because we have
already changed a lot of things related to dependency management.
> Evaluate and Update checksum and signature verification
> ---
>
> Key: SOLR-17657
> URL: https://issues.apache.org/jira/browse/SOLR-17657
> Project: Solr
> Issue Type: Improvement
> Components: Gradle
>Reporter: Christos Malliaridis
>Priority: Major
> Labels: checksum, gradle, integrity, verification
>
> Dependency verification is an important step that is used when we want to
> verify the integrity of third-party libraries. Right now, we have custom
> gradle tasks for generating and verifying the gradle checksums.
> These custom gradle tasks seem to be limited in their dependency resolution
> and do not check dependencies from plugins, buildSrc or integrated builds.
> Gradle comes with dependency verification options that also support signature
> checks, whereever availab
Re: [PR] SOLR-14414: Introduce new UI (SIP-7) [solr]
malliaridis commented on code in PR #2605: URL: https://github.com/apache/solr/pull/2605#discussion_r1947559396 ## gradle/libs.versions.toml: ## @@ -0,0 +1,65 @@ +[versions] Review Comment: I have looked into the way we generate and check the existing checksums, and I noticed that, because this module is a kotlin multiplatform module, it does not have the same configuration names used in the jar validation task (which are `runtimeClasspath`, `compileClasspath`, `testRuntimeClasspath`, `testCompileClasspath`). Therefore, no checksums or license checks are executed on this module yet. I have created [SOLR-17657](https://issues.apache.org/jira/browse/SOLR-17657) for a potentially more robust way of generating checksums and also add signature verification. The proposed changes would also cover the new multiplatform module, as well as configurations from plugins and other places. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-14414: Introduce new UI (SIP-7) [solr]
malliaridis commented on code in PR #2605: URL: https://github.com/apache/solr/pull/2605#discussion_r1947559847 ## solr/compose-ui/build.gradle.kts: ## @@ -0,0 +1,134 @@ +/* Review Comment: I have created [SOLR-17572](https://issues.apache.org/jira/browse/SOLR-17572). -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-14414: Introduce new UI (SIP-7) [solr]
malliaridis commented on code in PR #2605: URL: https://github.com/apache/solr/pull/2605#discussion_r1947559994 ## solr/compose-ui/src/commonMain/composeResources/font/firacode-variable.ttf: ## Review Comment: I have removed custom fonts for now, as I do not want to version binary / larger files. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17657) Evaluate and Update checksum and signature verification
Christos Malliaridis created SOLR-17657:
---
Summary: Evaluate and Update checksum and signature verification
Key: SOLR-17657
URL: https://issues.apache.org/jira/browse/SOLR-17657
Project: Solr
Issue Type: Improvement
Components: Gradle
Reporter: Christos Malliaridis
Dependency verification is an important step that is used when we want to
verify the integrity of third-party libraries. Right now, we have custom gradle
tasks for generating and verifying the gradle checksums.
These custom gradle tasks seem to be limited in their dependency resolution and
do not check dependencies from plugins, buildSrc or integrated builds.
Gradle comes with dependency verification options that also support signature
checks, whereever available. It is also capable of taking plugins and
configurations from buildSrc and integrated builds into account. See [Gradle
dependency
verification|https://docs.gradle.org/current/userguide/dependency_verification.html]
for more information.
h2. Task
Evaluate the output and the capabilities available of the Gradle-native
features from the above link and update the gradle tasks and development flows
if they are preferred.
You can use the gradle task
{{.\gradlew \-\-write-verification-metadata sha256 help}}
for generating your first output at {{gradle/verification-metadata.xml}}.
h2. Acceptance Criteria
- The GitHub workflows continue verifying checksums and optionally signatures
If updated to the Gradle-native tasks:
- The steps in our developer guide are updated accordingly
- redundant custom gradle tasks related to the checksum generation and
verification are removed
- Checksum files from {{solr/licenses}} are removed
h2. Additional Information
The new UI module introduced in #2605 is a Kotlin multiplatform module, which
does not use the JavaPlugin that is used for resolving jar information (see
jarValidation task). This means that it is not covered by our custom tasks.
We should try to address this issue before Solr 10 is released, because we have
already changed a lot of things related to dependency management.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17658) Implement Admin UI Start Screen
[ https://issues.apache.org/jira/browse/SOLR-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17658: Summary: Implement Admin UI Start Screen (was: Implement Start Screen) > Implement Admin UI Start Screen > --- > > Key: SOLR-17658 > URL: https://issues.apache.org/jira/browse/SOLR-17658 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: ui > > The new UI is built for web (shipped with Solr server and webapp) and desktop > (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the > API. In order to have an option to allow the user to select the Solr instance > (URL), a start screen was designed that should be displayed as initial screen > / entrypoint. > h2. Task > Implement the start screen according to the [designs from > Figma|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. > Only the first form where the user can provide a Solr URL is relevant for > this ticket. > h2. Acceptance Criteria > - When the user opens for the first time the new UI, the start screen is > displayed > - On desktop, the user can edit the Solr URL and provide a custom URL > - A placeholder to http://localhost:8983 is used on desktop as default value > for the Solr URL > - If the user is on web and accessed the Solr instance via a Solr URL, the > host from the current URL is used and the user is automatically connected > - When successfully connected, the user is redirected to the Dashboard (or > any existing screen for now) > - The provided Solr URL is used in the HTTP client > - The logout button redirects the user back to the start screen > h2. Additional Information > You should avoid handling authentication / authorization in this issue, as > this is addressed in a separate issue. The designs cover an authentication > form, but that can be ignored for now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17658) Implement Admin UI Start Screen
[ https://issues.apache.org/jira/browse/SOLR-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17658: Description: The new UI is built for web (shipped with Solr server and webapp) and desktop (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the API. In order to have an option to allow the user to select the Solr instance (URL), a start screen was designed that should be displayed as initial screen / entrypoint. h2. Task Implement the start screen according to the [new designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. Only the first form where the user can provide a Solr URL is relevant for this ticket. h2. Acceptance Criteria - When the user opens for the first time the new UI, the start screen is displayed - On desktop, the user can edit the Solr URL and provide a custom URL - A placeholder to http://localhost:8983 is used on desktop as default value for the Solr URL - If the user is on web and accessed the Solr instance via a Solr URL, the host from the current URL is used and the user is automatically connected - When successfully connected, the user is redirected to the Dashboard (or any existing screen for now) - The provided Solr URL is used in the HTTP client - The logout button redirects the user back to the start screen - A warning dialog is shown before connecting to an HTTP URL (see designs) h2. Additional Information You should avoid handling authentication / authorization in this issue, as this is addressed in a separate issue. The designs cover an authentication form, but that can be ignored for now. was: The new UI is built for web (shipped with Solr server and webapp) and desktop (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the API. In order to have an option to allow the user to select the Solr instance (URL), a start screen was designed that should be displayed as initial screen / entrypoint. h2. Task Implement the start screen according to the [designs from Figma|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. Only the first form where the user can provide a Solr URL is relevant for this ticket. h2. Acceptance Criteria - When the user opens for the first time the new UI, the start screen is displayed - On desktop, the user can edit the Solr URL and provide a custom URL - A placeholder to http://localhost:8983 is used on desktop as default value for the Solr URL - If the user is on web and accessed the Solr instance via a Solr URL, the host from the current URL is used and the user is automatically connected - When successfully connected, the user is redirected to the Dashboard (or any existing screen for now) - The provided Solr URL is used in the HTTP client - The logout button redirects the user back to the start screen h2. Additional Information You should avoid handling authentication / authorization in this issue, as this is addressed in a separate issue. The designs cover an authentication form, but that can be ignored for now. > Implement Admin UI Start Screen > --- > > Key: SOLR-17658 > URL: https://issues.apache.org/jira/browse/SOLR-17658 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > The new UI is built for web (shipped with Solr server and webapp) and desktop > (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the > API. In order to have an option to allow the user to select the Solr instance > (URL), a start screen was designed that should be displayed as initial screen > / entrypoint. > h2. Task > Implement the start screen according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. > Only the first form where the user can provide a Solr URL is relevant for > this ticket. > h2. Acceptance Criteria > - When the user opens for the first time the new UI, the start screen is > displayed > - On desktop, the user can edit the Solr URL and provide a custom URL > - A placeholder to http://localhost:8983 is used on desktop as default value > for the Solr URL > - If the user is on web and accessed the Solr instance via a Solr URL, the > host from the current URL is used and the user is automatically connected > - When successfully connected, the user is redirected to the Dashboard (or > any existing screen for now) > - The provided Solr URL is used in the HTTP client > - The logout button redirects the user back to the start screen > - A warning dialog is shown before connecting to an
[jira] [Updated] (SOLR-17658) Implement Admin UI Start Screen
[ https://issues.apache.org/jira/browse/SOLR-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17658: Labels: new-ui ui (was: ui) > Implement Admin UI Start Screen > --- > > Key: SOLR-17658 > URL: https://issues.apache.org/jira/browse/SOLR-17658 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > The new UI is built for web (shipped with Solr server and webapp) and desktop > (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the > API. In order to have an option to allow the user to select the Solr instance > (URL), a start screen was designed that should be displayed as initial screen > / entrypoint. > h2. Task > Implement the start screen according to the [designs from > Figma|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. > Only the first form where the user can provide a Solr URL is relevant for > this ticket. > h2. Acceptance Criteria > - When the user opens for the first time the new UI, the start screen is > displayed > - On desktop, the user can edit the Solr URL and provide a custom URL > - A placeholder to http://localhost:8983 is used on desktop as default value > for the Solr URL > - If the user is on web and accessed the Solr instance via a Solr URL, the > host from the current URL is used and the user is automatically connected > - When successfully connected, the user is redirected to the Dashboard (or > any existing screen for now) > - The provided Solr URL is used in the HTTP client > - The logout button redirects the user back to the start screen > h2. Additional Information > You should avoid handling authentication / authorization in this issue, as > this is addressed in a separate issue. The designs cover an authentication > form, but that can be ignored for now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16116) Refactor the Solr Zookeeper logic to use Apache Curator
[
https://issues.apache.org/jira/browse/SOLR-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925319#comment-17925319
]
David Smiley commented on SOLR-16116:
-
Found another failure of BasicDistributedZk2Test with same symptoms
({{ZkController.onReconnect}})
[here|https://productionresultssa0.blob.core.windows.net/actions-results/8597700e-072f-403c-81cc-2a3fe8b3ee54/workflow-job-run-5264e576-3c6f-51f6-f055-fab409685f20/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-02-08T17%3A23%3A06Z&sig=sBJBpj3ndhpyUSkc1MWdukc5bBKJJ0YPYytcj4iMzOU%3D&ske=2025-02-09T04%3A56%3A25Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-02-08T16%3A56%3A25Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-01-05&sp=r&spr=https&sr=b&st=2025-02-08T17%3A13%3A01Z&sv=2025-01-05].
The onReconnect is registered as a listener, so not trivial to schedule to
ensure this happens before ZkController.close.
I'm thinking we may need a ReadWriteLock instead of isClosed in ZkController.
Any method that today checks isClosed would instead try to grab a read lock and
immediately give up if it can't (means ZkController is shutting down).
Acquiring the read lock will block close(); close() would grab the write lock
and never close it, as it signifies the final conclusion of ZkController. WDYT
[~houston]? I could take a stab at this.
> Refactor the Solr Zookeeper logic to use Apache Curator
> ---
>
> Key: SOLR-16116
> URL: https://issues.apache.org/jira/browse/SOLR-16116
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0)
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925320#comment-17925320 ] Gus Heck commented on SOLR-17659: - I suspect you probably already intend it but to be explicit I think we also want these criteria. * Authentication is not required to see the login form (pretty obvious) * _*Only*_ the login form and it's dedicated images/js/css can be viewed without authentication, no other services or files are available (and no info useful to attackers about the version of solr or jetty etc is exposed) Additionally I think rather than "basic auth" this should work with "whatever auth is configured for solr as a whole" So if they are using JWT, the login should redirect to the JWT token provider login, and if they have the appropriate token already, it should not show up. I think the best strategy is to have this be an entirely separate application context so that it just simply has no access to any solr code at all, and have a servlet filter around the solr stuff that redirects to it if authentication is not satisfied. I know this is pretty far out of the UI realm, but login page design really has to work with a backend, and the way we do it now we are already well into SolrDispatchFilter before auth is checked which makes it hard to protect the UI in the same manner as the services. Finally in the design I don't understand "back" or what Start Screen would be in the criteria above. If authentication is enabled, there should be nothing visible other than the login screen (and it's required resources). > Implement basic authentication in Admin UI > -- > > Key: SOLR-17659 > URL: https://issues.apache.org/jira/browse/SOLR-17659 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > In the new UI one of the key features that is not implemented yet is user > authentication. In order to secure and securily access Solr, the user should > be able to authenticate against a Solr instance with basic credentials. > h2. Task > Implement basic user authentication (with credentials) according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1]. > h2. Acceptance Criteria > - The user can access a Solr instance that has user authentication enabled > - The user can at least authenticate with credentials (basic auth) > - The credentials form is displayed after the user has established a > connection with a Solr instance, that is, after a Solr instance was found > - The user can return to the start screen where the Solr URL was provided, if > he decides to abort the authentication step > - The user is no longer redirected to the dashboard or any other screen if > user authentication is required > - The credentials are used for any subsequent request > h2. Additional Information > The support for additional authentication options does not have to be > addressed in this issue. If it proves to be straight-forward, feel free to > implement additional auth options as well. > The credentials do not have to survive an application restart (desktop). > Storing credentials securely will be addressed in a separate issue. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17660) Implement basic list component in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17660: Description: Many UI elements in the new designs of the Admin UI use a table-like or list component with a filter on top and some actions left and right. This component can be implemented in a way that can be reused, allowing a quicker implementation of components that follow the same pattern. h2. Task Implement a reusable list component that is for now based on the needs of the list shown in the logging section. Use the logging section as first implementation for evaluation of the UI component's "interface". h2. Acceptance Criteria - The top bar (input field) has dynamic actions on the right - The action on the left can optionally be added / displayed - The input can be cleared with a clear button \(x) - The clear button \(x) is hidden when the input is empty - The child elements are passed by the parent (are dynamic) - The list is horizontally scrollable if a child is longer than the available width - The list is vertically scrollable if the amount of children exceed the available height For the logs in the logging section it is sufficient to keep it simple and only display the values of the field. Another ticket will add additional functionality and support (like coloring and wrapping). h2. Additional Information You do not have to add support for a header / column names. That comes with additional requirements like sorting, that should be avoided for now. Do not aim for perfection, as not all requirements are clarified right now. If there is a ready-to-use component from a compose UI libary that can be used and simply styled, consider using that instead. was: Many UI elements in the new designs of the Admin UI use a table-like or list component with a filter on top and some actions left and right. This component can be implemented in a way that can be reused, allowing a quicker implementation of components that follow the same pattern. h2. Task Implement a reusable list component that is for now based on the needs of the list shown in the logging section. Use the logging section as first implementation for evaluation of the UI component's "interface". h2. Acceptance Criteria - The top bar (input field) has dynamic actions on the right - The action on the left can optionally be added / displayed - The input can be cleared with a clear button (x) - The clear button (x) is hidden when the input is empty - The child elements are passed by the parent (are dynamic) - The list is horizontally scrollable if a child is longer than the available width - The list is vertically scrollable if the amount of children exceed the available height For the logs in the logging section it is sufficient to keep it simple and only display the values of the field. Another ticket will add additional functionality and support (like coloring and wrapping). h2. Additional Information You do not have to add support for a header / column names. That comes with additional requirements like sorting, that should be avoided for now. Do not aim for perfection, as not all requirements are clarified right now. If there is a ready-to-use component from a compose UI libary that can be used and simply styled, consider using that instead. > Implement basic list component in Admin UI > -- > > Key: SOLR-17660 > URL: https://issues.apache.org/jira/browse/SOLR-17660 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > Many UI elements in the new designs of the Admin UI use a table-like or list > component with a filter on top and some actions left and right. This > component can be implemented in a way that can be reused, allowing a quicker > implementation of components that follow the same pattern. > h2. Task > Implement a reusable list component that is for now based on the needs of the > list shown in the logging section. Use the logging section as first > implementation for evaluation of the UI component's "interface". > h2. Acceptance Criteria > - The top bar (input field) has dynamic actions on the right > - The action on the left can optionally be added / displayed > - The input can be cleared with a clear button \(x) > - The clear button \(x) is hidden when the input is empty > - The child elements are passed by the parent (are dynamic) > - The list is horizontally scrollable if a child is longer than the available > width > - The list is vertically scrollable if the amount of children exceed the > available height > For the logs in the logging section it is sufficient to keep it simple and > only display the values of the field. Another ticket will add
[jira] [Created] (SOLR-17660) Implement basic list component in Admin UI
Christos Malliaridis created SOLR-17660: --- Summary: Implement basic list component in Admin UI Key: SOLR-17660 URL: https://issues.apache.org/jira/browse/SOLR-17660 Project: Solr Issue Type: New Feature Components: Admin UI Reporter: Christos Malliaridis Many UI elements in the new designs of the Admin UI use a table-like or list component with a filter on top and some actions left and right. This component can be implemented in a way that can be reused, allowing a quicker implementation of components that follow the same pattern. h2. Task Implement a reusable list component that is for now based on the needs of the list shown in the logging section. Use the logging section as first implementation for evaluation of the UI component's "interface". h2. Acceptance Criteria - The top bar (input field) has dynamic actions on the right - The action on the left can optionally be added / displayed - The input can be cleared with a clear button (x) - The clear button (x) is hidden when the input is empty - The child elements are passed by the parent (are dynamic) - The list is horizontally scrollable if a child is longer than the available width - The list is vertically scrollable if the amount of children exceed the available height For the logs in the logging section it is sufficient to keep it simple and only display the values of the field. Another ticket will add additional functionality and support (like coloring and wrapping). h2. Additional Information You do not have to add support for a header / column names. That comes with additional requirements like sorting, that should be avoided for now. Do not aim for perfection, as not all requirements are clarified right now. If there is a ready-to-use component from a compose UI libary that can be used and simply styled, consider using that instead. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947968424
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
> ClusterStateProviderTest: looks like just needs to convert both maps to
the same type (e.g. wrap in HashMap
Where would I do that? There is really a lot happening in those tests and I
still have not managed to fully wrap my head around it.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[
https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925328#comment-17925328
]
Christos Malliaridis commented on SOLR-17659:
-
As Jan correctly said, the new UI is a client side application that only
interacts with Solr via the existing API. The new UI is "just a client with a
user interface" that loads Solr information only via Solr's existing API. So
even if all "pages" of the UI are accessible or the login form is "bypassed",
the user won't get any information about Solr through the new UI if the API is
properly requiring and checking the necessary authentication / authorization.
{quote}Additionally I think rather than "basic auth" this should work with
"whatever auth is configured for solr as a whole" So if they are using JWT, the
login should redirect to the JWT token provider login, and if they have the
appropriate token already, it should not show up.
{quote}
I agree, that is the goal and what we aim for, to support all authentication
options that can be configured in Solr. I even want to support multiple auth
options if more than one is configured. However, since I expect a larger
workload when we try to address all authentication options at the same time,
this issue focuses only on the basic auth with credentials for now. Bringing
support for the rest should be addressed one by one and in separate tickets, so
that the scope of each issue stays managable.
{quote}Finally in the design I don't understand "back" or what Start Screen
would be in the criteria above. If authentication is enabled, there should be
nothing visible other than the login screen (and it's required resources).
{quote}
To understand the requirement here, it is important to distinguish between a
desktop client that can connect to any Solr instance via a URL the user
provides, and the web-browser that is deployed right now with an existing Solr
instance and accessed with the according URL from the browser window (this
means, the Solr URL is already known and fix). In the scenario of a desktop
client, the users have the "start screen" where they can type in the URL of a
Solr instance. Once they provide a valid URL and hit "connect", it will check
if there is for that specific instance authentication required. If so, the next
"form" will be the authentication form. In case the user decides to "abort" and
go back to type in another instance URL, there should be a back button to go
back to the previous form.
If we look at the browser variant only, the "start screen" has only one purpose
right now, and that is to check if authentication is required and show the
login form if that is the case. Theoretically, other error handling options
like for "service unavailable (HTTP 503)" could be added in the future, so that
if a solr instance is unavailable during an update or so, the UI could still be
displaying a helpful message like "please try again in a few minutes" (if it is
of course available).
And about OAuth and OIDC, I am not sure about Solr's current state, but I
believe that using an external Identity Provider with OAuth/OIDC support, Solr
would be just a "resource server" in terms of OAuth, those the sole
responsibility of Solr's API would be to verify the tokens provided by requests
like from the new UI and grant / refuse access. Not sure if we need additional
changes on Solr's part. The new UI on the other hand would have to follow the
"Authorization Code Flow with Proof Key for Code Exchange (PKCE)", which does
not require a client secret to be shipped with the client, which otherwise
could easily be extracted from browser and from the standalone client. But that
is a discussion for the follow-up issue that addresses OAuth/OIDC support in
the new UI. :)
> Implement basic authentication in Admin UI
> --
>
> Key: SOLR-17659
> URL: https://issues.apache.org/jira/browse/SOLR-17659
> Project: Solr
> Issue Type: New Feature
> Components: Admin UI
>Reporter: Christos Malliaridis
>Priority: Major
> Labels: new-ui, ui
>
> In the new UI one of the key features that is not implemented yet is user
> authentication. In order to secure and securily access Solr, the user should
> be able to authenticate against a Solr instance with basic credentials.
> h2. Task
> Implement basic user authentication (with credentials) according to the [new
> designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1].
> h2. Acceptance Criteria
> - The user can access a Solr instance that has user authentication enabled
> - The user can at least authenticate with credentials (basic auth)
> - The credentials form is displayed after the user has established a
> connection
[jira] [Resolved] (SOLR-10710) LTR contrib failures
[
https://issues.apache.org/jira/browse/SOLR-10710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-10710.
-
Resolution: Fixed
Closing. The failures listed no longer fail since 2023 at the latest, except
maybe TestLTRQParserPlugin but not the specific test method listed.
> LTR contrib failures
>
>
> Key: SOLR-10710
> URL: https://issues.apache.org/jira/browse/SOLR-10710
> Project: Solr
> Issue Type: Bug
> Components: contrib - LTR
>Reporter: Steven Rowe
>Priority: Major
> Fix For: 7.0
>
>
> Reproducing failures
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1304/] - {{git
> bisect}} says {{06a6034d9}}, the commit on LUCENE-7730, is where the
> {{TestFieldLengthFeature.testRanking()}} failure started:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestFieldLengthFeature -Dtests.method=testRanking
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=ja-JP
> -Dtests.timezone=America/Port_of_Spain -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.06s J1 | TestFieldLengthFeature.testRanking <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '8'!='1'
> @ response/docs/[0]/id
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:EB385C1332233915]:0)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]> at
> org.apache.solr.ltr.feature.TestFieldLengthFeature.testRanking(TestFieldLengthFeature.java:117)
> {noformat}
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestParallelWeightCreation
> -Dtests.method=testLTRScoringQueryParallelWeightCreationResultOrder
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=ar-SD
> -Dtests.timezone=Europe/Skopje -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 1.59s J1 |
> TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder
> <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='4'
> @ response/docs/[0]/id
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:1142D5ED603B4132]:0)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]> at
> org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder(TestParallelWeightCreation.java:45)
> {noformat}
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestSelectiveWeightCreation
> -Dtests.method=testSelectiveWeightsRequestFeaturesFromDifferentStore
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=hr-HR
> -Dtests.timezone=Australia/Victoria -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.03s J1 |
> TestSelectiveWeightCreation.testSelectiveWeightsRequestFeaturesFromDifferentStore
> <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='4'
> @ response/docs/[0]/id
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:293FE248276551B1]:0)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]> at
> org.apache.solr.ltr.TestSelectiveWeightCreation.testSelectiveWeightsRequestFeaturesFromDifferentStore(TestSelectiveWeightCreation.java:230)
> {noformat}
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLTRQParserPlugin -Dtests.method=ltrMoreResultsThanReRankedTest
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=es-NI
> -Dtests.timezone=Africa/Mogadishu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.03s J1 |
> TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch:
> '0.09271725'!='0.105360515' @ response/docs/[3]/score
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:BD7644EA7596711B]:0)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]> at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]> at
> org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SOLR-17661) Flaky test: TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
David Smiley created SOLR-17661:
---
Summary: Flaky test:
TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
Key: SOLR-17661
URL: https://issues.apache.org/jira/browse/SOLR-17661
Project: Solr
Issue Type: Test
Components: contrib - LTR
Reporter: David Smiley
TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
is flaky (aka a flapper). See
[develocity|https://develocity.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.ltr.TestLTRQParserPlugin&tests.test=ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults]
and
[fucit|http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.ltr.TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults].
{noformat}
java.lang.AssertionError: mismatch: '4'!='0' @ response/numFound
2025-02-08T16:59:43.0317686Z at
__randomizedtesting.SeedInfo.seed([8D9A051D8B7F602C:3DA5B3239B06B220]:0)
2025-02-08T16:59:43.0321872Z at org.junit.Assert.fail(Assert.java:89)
2025-02-08T16:59:43.0322542Z at
org.apache.solr.util.RestTestBase.assertJsonMatches(RestTestBase.java:268)
2025-02-08T16:59:43.0323357Z at
org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:210)
2025-02-08T16:59:43.0326697Z at
org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:182)
2025-02-08T16:59:43.0331325Z at
org.apache.solr.ltr.TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults(TestLTRQParserPlugin.java:160)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17661) Flaky test: TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
[
https://issues.apache.org/jira/browse/SOLR-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925330#comment-17925330
]
David Smiley commented on SOLR-17661:
-
I suspect the Gradle test-retry plugin confuses Fucit and/or Jenkins, so it
maybe doesn't see flakyness here? Not important. Although Fucit does see
[another LTR
failure|http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.ltr.TestLTRQParserPlugin.ltr_expensiveFeatureRescoringAndPartialResultsNotTolerated_shouldRaiseException]
for a nearby method.
> Flaky test:
> TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
> ---
>
> Key: SOLR-17661
> URL: https://issues.apache.org/jira/browse/SOLR-17661
> Project: Solr
> Issue Type: Test
> Components: contrib - LTR
>Reporter: David Smiley
>Priority: Minor
>
> TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults
> is flaky (aka a flapper). See
> [develocity|https://develocity.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.ltr.TestLTRQParserPlugin&tests.test=ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults]
> and
> [fucit|http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.ltr.TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults].
> {noformat}
> java.lang.AssertionError: mismatch: '4'!='0' @ response/numFound
> 2025-02-08T16:59:43.0317686Z at
> __randomizedtesting.SeedInfo.seed([8D9A051D8B7F602C:3DA5B3239B06B220]:0)
> 2025-02-08T16:59:43.0321872Z at org.junit.Assert.fail(Assert.java:89)
> 2025-02-08T16:59:43.0322542Z at
> org.apache.solr.util.RestTestBase.assertJsonMatches(RestTestBase.java:268)
> 2025-02-08T16:59:43.0323357Z at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:210)
> 2025-02-08T16:59:43.0326697Z at
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:182)
> 2025-02-08T16:59:43.0331325Z at
> org.apache.solr.ltr.TestLTRQParserPlugin.ltr_expensiveFeatureRescoring_shouldTimeOutAndReturnPartialResults(TestLTRQParserPlugin.java:160)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17659) Implement basic authentication in Admin UI
Christos Malliaridis created SOLR-17659: --- Summary: Implement basic authentication in Admin UI Key: SOLR-17659 URL: https://issues.apache.org/jira/browse/SOLR-17659 Project: Solr Issue Type: Improvement Components: Admin UI Reporter: Christos Malliaridis In the new UI one of the key features that is not implemented yet is user authentication. In order to secure and securily access Solr, the user should be able to authenticate against a Solr instance with basic credentials. h2. Task Implement basic user authentication (with credentials) according to the [new designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1]. h2. Acceptance Criteria - The user can access a Solr instance that has user authentication enabled - The user can at least authenticate with credentials (basic auth) - The credentials form is displayed after the user has established a connection with a Solr instance, that is, after a Solr instance was found - The user can return to the start screen where the Solr URL was provided, if he decides to abort the authentication step - The user is no longer redirected to the dashboard or any other screen if user authentication is required - The credentials are used for any subsequent request h2. Additional Information The support for additional authentication options does not have to be addressed in this issue. If it proves to be straight-forward, feel free to implement additional auth options as well. The credentials do not have to survive an application restart (desktop). Storing credentials securely will be addressed in a separate issue. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] chore(deps): update dependency org.junit.jupiter:junit-jupiter to v5.11.4 [solr]
solrbot opened a new pull request, #3168: URL: https://github.com/apache/solr/pull/3168 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.junit.jupiter:junit-jupiter](https://junit.org/junit5/) ([source](https://redirect.github.com/junit-team/junit5)) | dependencies | minor | `5.8.1` -> `5.11.4` | --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/solrbot/renovate-github-action) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17658) Implement Start Screen
Christos Malliaridis created SOLR-17658: --- Summary: Implement Start Screen Key: SOLR-17658 URL: https://issues.apache.org/jira/browse/SOLR-17658 Project: Solr Issue Type: Improvement Components: Admin UI Reporter: Christos Malliaridis The new UI is built for web (shipped with Solr server and webapp) and desktop (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the API. In order to have an option to allow the user to select the Solr instance (URL), a start screen was designed that should be displayed as initial screen / entrypoint. h2. Task Implement the start screen according to the [designs from Figma|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. Only the first form where the user can provide a Solr URL is relevant for this ticket. h2. Acceptance Criteria - When the user opens for the first time the new UI, the start screen is displayed - On desktop, the user can edit the Solr URL and provide a custom URL - A placeholder to http://localhost:8983 is used on desktop as default value for the Solr URL - If the user is on web and accessed the Solr instance via a Solr URL, the host from the current URL is used and the user is automatically connected - When successfully connected, the user is redirected to the Dashboard (or any existing screen for now) - The provided Solr URL is used in the HTTP client - The logout button redirects the user back to the start screen h2. Additional Information You should avoid handling authentication / authorization in this issue, as this is addressed in a separate issue. The designs cover an authentication form, but that can be ignored for now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-14414: Introduce new UI (SIP-7) [solr]
malliaridis merged PR #2605: URL: https://github.com/apache/solr/pull/2605 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925206#comment-17925206
]
ASF subversion and git services commented on SOLR-14414:
Commit bb27d3e4047dc50849e4c42d7d6bac1119003805 in solr's branch
refs/heads/main from Christos Malliaridis
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=bb27d3e4047 ]
SOLR-14414: Introduce new UI (SIP-7) (#2605)
* Add basic Compose integration example for webapp
This commit creates a new module in Solr that sets up a
frontend written with Compose and targeting browser (WASM)
and desktop (JVM).
The webapp is modified so that it opens the WASM Compose app
when accessing /solr/compose.
IMPORTANT: The jetty configuration is updated to include
script-src: 'wasm-unsafe-eval' to allow WASM code execution
which may be considered a security issue.
* Add dev-docs for UI development with Kotlin/Compose
* Improve build times via development flag
This commit adds a development flag to our
gradle.properties that allows the selection of
the build variant for the new AdminUI. When
development enabled (default), Gradle will build
a development instance and will have less secure
configuration for the AdminUI to be able to attach
debugging tools.
When disabled, Gradle will optimize build output
for the new Admin UI, but will also take longer to
complete.
Default is set to true to always build development
locally and in CI/CD to avoid longer building times.
Additionally, user is able to disable the new AdminUI
via SOLR_ADMIN_UI_EXPERIMENTAL_DISABLED or by disabling
the AdminUI.
IMPORTANT: From this commit on, during releases, the
development flag needs to be set explicitly to false,
otherwise it will not generate an optimized Admin UI
with improved CSP directives.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Affects Versions: 9.0
>Reporter: Marcus Eagan
>Priority: Major
> Labels: pull-request-available
> Attachments: QueryUX-SolrAdminUIReboot.mov
>
> Time Spent: 10h
> Remaining Estimate: 0h
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
> Discussion in mailing list:
> https://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAF76exK-EB_tyFx0B4fBiA%3DJj8gH%3Divn2Uo6cWvMwhvzRdA3KA%40mail.gmail.com%3E
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17635: unmarshalling Map to SimpleOrderedMap if key i of type St… [solr]
renatoh commented on code in PR #3163:
URL: https://github.com/apache/solr/pull/3163#discussion_r1947547033
##
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java:
##
@@ -293,7 +306,7 @@ public void testForwardCompat() throws IOException {
for (int i = 1;
i < currentFormatBytes.length;
i++) { // ignore the first byte. It is version information
- assertEquals(newFormatBytes[i], currentFormatBytes[i]);
+ assertEquals("for i:" + i, newFormatBytes[i], currentFormatBytes[i]);
Review Comment:
All the tests in TestJavaBinCodec do not need to pass with
javabin.setMapAsNamedList=true even though it will be true by default? I would
have thought all these test need to pass in order to ensure we do not break
anything by changing to SOM.
In this case, there is also no need to update /solrj/javabin_backcompat.bin?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[PR] chore(deps): update kotlin to v2.1.10 [solr]
solrbot opened a new pull request, #3167: URL: https://github.com/apache/solr/pull/3167 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | org.jetbrains.kotlin.plugin.serialization | plugin | patch | `2.1.0` -> `2.1.10` | | org.jetbrains.kotlin.multiplatform | plugin | patch | `2.1.0` -> `2.1.10` | | org.jetbrains.kotlin.plugin.compose | plugin | patch | `2.1.0` -> `2.1.10` | | [org.jetbrains.kotlin:kotlin-stdlib-jdk8](https://kotlinlang.org/) ([source](https://redirect.github.com/JetBrains/kotlin)) | dependencies | patch | `2.1.0` -> `2.1.10` | --- ### Release Notes JetBrains/kotlin (org.jetbrains.kotlin:kotlin-stdlib-jdk8) ### [`v2.1.10`](https://redirect.github.com/JetBrains/kotlin/blob/HEAD/ChangeLog.md#2110) # Compiler - [`KT-73858`](https://youtrack.jetbrains.com/issue/KT-73858) Compose / iOS: NullPointerException on building - [`KT-73454`](https://youtrack.jetbrains.com/issue/KT-73454) K2: Fix type parameters mapping for typealiases with inner RHS - [`KT-73043`](https://youtrack.jetbrains.com/issue/KT-73043) K2 Compiler does not allow references to inner constructors with typealiases - [`KT-74040`](https://youtrack.jetbrains.com/issue/KT-74040) Compilation of inner class usage does not check the visibility of parent class during compilation in different rounds - [`KT-73339`](https://youtrack.jetbrains.com/issue/KT-73339) K2: "VerifyError: Bad type on operand stack" because of missing implicit cast on generic field receiver with star projection - [`KT-72585`](https://youtrack.jetbrains.com/issue/KT-72585) K2: Compilation failure when upgrading to Kotlin 2.0.20+: Cannot replace top-level type with star projection: S - [`KT-73399`](https://youtrack.jetbrains.com/issue/KT-73399) compile-time JVM codegen failure on a KProperty argument of a KSuspendFunction parameter - [`KT-72725`](https://youtrack.jetbrains.com/issue/KT-72725) KMP: Unsupported actualization of inherited java field in expect class - [`KT-73153`](https://youtrack.jetbrains.com/issue/KT-73153) K2: Standalone diagnostics on type arguments are not reported # Compose compiler - [`CMP-5680`](https://youtrack.jetbrains.com/issue/CMP-5680) Compose compiler: unexpected stability warnings for classes compiled with 2.0.10 - [`b/381407900`](https://issuetracker.google.com/issues/381407900) Avoid adding Compose annotations on synthetic classes # IR. Inlining - [`KT-73981`](https://youtrack.jetbrains.com/issue/KT-73981) Cherry-pick the fix for KT-73482 to 2.1.10 # JavaScript - [`KT-70778`](https://youtrack.jetbrains.com/issue/KT-70778) Kotlin Js companion is undefined in production build - [`KT-73130`](https://youtrack.jetbrains.com/issue/KT-73130) KJS: Missed `break` for do/while in generated JS code - [`KT-58797`](https://youtrack.jetbrains.com/issue/KT-58797) Optimize the code generated for objects on JS and Wasm backends # Klibs - [`KT-70146`](https://youtrack.jetbrains.com/issue/KT-70146) \[KLIB Resolve] Don't fail on nonexistent transitive dependency - [`KT-73951`](https://youtrack.jetbrains.com/issue/KT-73951) Workaround for "Partial linkage engine may not patch some discrepancies in IR when compiling Kotlin/Native static caches" in 2.1.10 # Native - [`KT-73559`](https://youtrack.jetbrains.com/issue/KT-73559) K/Native: AndroidNativeArm64 linking fails starting from Kotlin 2.1.0 # Tools. CLI - [`KT-73967`](https://youtrack.jetbrains.com/issue/KT-73967) JDK 25: "IllegalArgumentException: 25-ea" with EA builds # Tools. Daemon - [`KT-73311`](https://youtrack.jetbrains.com/issue/KT-73311) "Unable to release compile session, maybe daemon is already down" flakiness # Tools. Gradle - [`KT-73728`](https://youtrack.jetbrains.com/issue/KT-73728) 'generatePomFileForMavenPublication' creates pom with dependencies with 'unspecified' version # Tools. Gradle. Multiplatform - [`KT-73620`](https://youtrack.jetbrains.com/issue/KT-73620) KMP 2.1.0: Transitive dependency is broken when setting publication groupId # Tools. Gradle. Native - [`KT-73572`](https://youtrack.jetbrains.com/issue/KT-73572) \[Gradle] `kotlin.native.cacheKind=none` doesn't work anymore - [`KT-71419`](https://youtrack.jetbrains.com/issue/KT-71419) Light bundle KGP IT run against a stable K/N version --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925323#comment-17925323 ] Jan Høydahl commented on SOLR-17659: This is an exciting part of the UI, and I see where you're coming from Gus. But before we dive deep into your proposals, let's make clear the scope of the first version of the new UI. The new UI is a client side application which hits Solr's normal REST APIs. There is not dedicated admin-UI backend component/servlet, thus any authentication that can be done on top of existing Solr backend must use Solr's existing auth capabilities, and each and every call from the UI app must carry the "Authorization" header. There is really not "login" or "logout" or session. Thus I think the scope of supporting BasicAuth only from the get-go is a good one. I feel your pain Gus about Solr's home-made auth framework. It would be nice to have a better version, but it's a totally separate effort. Wrt the JWT and OIDC auth, it is currently implemented on the client side (JS) and the browser keeps a long-lived bearer token. It is not the best solution, and we should really not go that direction with the new UI. Ideally we should have a new ui-backend servlet that takes care of code-flow with client-secret, session handling, issuing cookie to the new UI etc. Such a servlet should ideally take all UI traffic and proxy it to the Solr APIs, and it should be deploable either on a normal Solr node or on a dedicated UI backend node (using node roles). Such a UI backend could then de-couple human auth methods from the auth necessary to impelement on solr backends, and even if a user loggs in with OIDC to the UI backend, the requests sent to the solr nodes could use a different auth, such as mTLS or basicAuth. > Implement basic authentication in Admin UI > -- > > Key: SOLR-17659 > URL: https://issues.apache.org/jira/browse/SOLR-17659 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Priority: Major > Labels: new-ui, ui > > In the new UI one of the key features that is not implemented yet is user > authentication. In order to secure and securily access Solr, the user should > be able to authenticate against a Solr instance with basic credentials. > h2. Task > Implement basic user authentication (with credentials) according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1]. > h2. Acceptance Criteria > - The user can access a Solr instance that has user authentication enabled > - The user can at least authenticate with credentials (basic auth) > - The credentials form is displayed after the user has established a > connection with a Solr instance, that is, after a Solr instance was found > - The user can return to the start screen where the Solr URL was provided, if > he decides to abort the authentication step > - The user is no longer redirected to the dashboard or any other screen if > user authentication is required > - The credentials are used for any subsequent request > h2. Additional Information > The support for additional authentication options does not have to be > addressed in this issue. If it proves to be straight-forward, feel free to > implement additional auth options as well. > The credentials do not have to survive an application restart (desktop). > Storing credentials securely will be addressed in a separate issue. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
