[PR] SOLR-13748: Add support for mm parameter to bool query parser (#2025) [solr]
mkhludnev opened a new pull request, #2127: URL: https://github.com/apache/solr/pull/2127 https://issues.apache.org/jira/browse/SOLR-13748 -- 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-13748: Add support for mm parameter to bool query parser [solr]
mkhludnev merged PR #2025: URL: https://github.com/apache/solr/pull/2025 -- 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-13748) mm (min should match) param for {!bool} query parser
[
https://issues.apache.org/jira/browse/SOLR-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794563#comment-17794563
]
ASF subversion and git services commented on SOLR-13748:
Commit c0c2099899180b9d77002f3749a664b931a72698 in solr's branch
refs/heads/main from Andrey Bozhko
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c0c20998991 ]
SOLR-13748: Add support for mm parameter to bool query parser (#2025)
-
Co-authored-by: Andrey Bozhko
Co-authored-by: Mikhail Khludnev
> mm (min should match) param for {!bool} query parser
>
>
> Key: SOLR-13748
> URL: https://issues.apache.org/jira/browse/SOLR-13748
> Project: Solr
> Issue Type: Sub-task
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Time Spent: 2h
> 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
Re: [PR] tests-via-crave.yml - switch to the correct branch for the PR [solr]
dsmiley merged PR #2124: URL: https://github.com/apache/solr/pull/2124 -- 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-15484) Frequent test failures for JWTAuthPluginIntegrationTest
[
https://issues.apache.org/jira/browse/SOLR-15484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794477#comment-17794477
]
James Dyer commented on SOLR-15484:
---
[~Don-vip] Would you be willing to try the latest changes in [PR
#2099|https://github.com/apache/solr/pull/2099] with your setup?
> Frequent test failures for JWTAuthPluginIntegrationTest
> ---
>
> Key: SOLR-15484
> URL: https://issues.apache.org/jira/browse/SOLR-15484
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Example:
> Build: [https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/1053/]
> {code}
> 1 tests failed.
> FAILED:
> org.apache.solr.security.JWTAuthPluginIntegrationTest.mockOAuth2Server
> Error Message:
> org.junit.ComparisonFailure: Should have received 401 code expected:<[401]>
> but was:<[200]>
> Stack Trace:
> org.junit.ComparisonFailure: Should have received 401 code expected:<[401]>
> but was:<[200]>
> at __randomizedtesting.SeedInfo.seed([7827798BF4D91EFE:FF2798DB9165E212]:0)
> at org.junit.Assert.assertEquals(Assert.java:117)
> at
> org.apache.solr.security.JWTAuthPluginIntegrationTest.mockOAuth2Server(JWTAuthPluginIntegrationTest.java:143)
> ...
> {code}
> The other test failure is
> {code}
> org.apache.solr.security.JWTAuthPluginTest.initWithInvalidTrustedCertsFile
> Failing for the past 1 build (Since #924 )
> Took 7 ms.
> Error Message
> junit.framework.AssertionFailedError: Expected exception SolrException but no
> exception was thrown
> Stacktrace
> junit.framework.AssertionFailedError: Expected exception SolrException but no
> exception was thrown
> at
> __randomizedtesting.SeedInfo.seed([8651FF5FA6DE29A1:91C33C9AFD0459B5]:0)
> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2863)
> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2849)
> at
> org.apache.solr.security.JWTAuthPluginTest.initWithInvalidTrustedCertsFile(JWTAuthPluginTest.java:521)
> ...
> {code}
--
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-17053) Distributed search: if all shards fail, fail the request despite shards.tolerant
[ https://issues.apache.org/jira/browse/SOLR-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794474#comment-17794474 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-17053: -- Thanks for the fix [~aparnasuresh]! > Distributed search: if all shards fail, fail the request despite > shards.tolerant > > > Key: SOLR-17053 > URL: https://issues.apache.org/jira/browse/SOLR-17053 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 8.6 >Reporter: Aparna Suresh >Priority: Minor > Fix For: 9.5 > > Time Spent: 2h > Remaining Estimate: 0h > > If the request is tolerant to errors, logic in SearchHandler simply sets > partialResults to true upon detecting an error in ShardResponse. This means a > failure to query any shard would be reported back as partialResults=true, > instead of a query failure. > Why: Improve the error handling and reporting in the search system by making > sure that query failures are distinct from partial results -- 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-17053) Distributed search: if all shards fail, fail the request despite shards.tolerant
[ https://issues.apache.org/jira/browse/SOLR-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794473#comment-17794473 ] ASF subversion and git services commented on SOLR-17053: Commit 061633d6bd9ccef0932e0379099bbe02841a22c8 in solr's branch refs/heads/branch_9x from aparnasuresh85 [ https://gitbox.apache.org/repos/asf?p=solr.git;h=061633d6bd9 ] SOLR-17053: Address ClassCastException issue (#2123) > Distributed search: if all shards fail, fail the request despite > shards.tolerant > > > Key: SOLR-17053 > URL: https://issues.apache.org/jira/browse/SOLR-17053 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 8.6 >Reporter: Aparna Suresh >Priority: Minor > Fix For: 9.5 > > Time Spent: 2h > Remaining Estimate: 0h > > If the request is tolerant to errors, logic in SearchHandler simply sets > partialResults to true upon detecting an error in ShardResponse. This means a > failure to query any shard would be reported back as partialResults=true, > instead of a query failure. > Why: Improve the error handling and reporting in the search system by making > sure that query failures are distinct from partial results -- 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-16880: Add OAS to 'assembleRelease' task [solr]
dsmiley commented on PR #2125: URL: https://github.com/apache/solr/pull/2125#issuecomment-1846233632 Does anything test this, or must it be manually inspected? Basically, how do we have confidence that this is basically working? -- 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-16880: Add OAS to 'assembleRelease' task [solr]
dsmiley commented on code in PR #2125:
URL: https://github.com/apache/solr/pull/2125#discussion_r1419745012
##
solr/api/build.gradle:
##
@@ -28,7 +28,7 @@ ext {
jsClientDir = "${buildDir}/generated/js"
pythonClientDir = "${buildDir}/generated/python"
openApiSpecDir = "${buildDir}/generated/openapi"
-openApiSpecFile = "${project.openApiSpecDir}/openapi.json"
+openApiSpecFile = "${project.openApiSpecDir}/solr-${version}-openapi.json"
Review Comment:
For JARs, the version is at the end. Maybe we should do similar? Just a
thought.
--
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-15484 JWTAuthPluginIntegrationTest - dynamically generate the self-signed certificate using the localhost loopback address [solr]
jdyer1 commented on PR #2099: URL: https://github.com/apache/solr/pull/2099#issuecomment-1846231319 @janhoy With my last update, I am cautiously optimistic this PR may help us with the failure rate. With this change, the test passes even if I change `localhost` to `localhost.localdomain` in my `/etc/hosts` file. (I am trying this as a modest attempt to mimic the environmental conditions when it fails in our CI.) However, carefully consider the changes I am making to `JWTIssuerConfig.java`. Here I am assuming the host name check bypass for `localhost` exists merely to help unit tests with self-signed certificates. Perhaps we are also helping users who try this functionality on their laptops? I think with my change it will work for either case, but maybe we also want to exempt `InetAddress.getLoopbackAddress().getHostName()` as well (as far as I can tell this will always return `localhost`). It would be much better if we could use the Mock library's self-signed certificate generation, as you suggest. This would greatly streamline this test and keep the focus were it belongs! Unfortunately with the short amount of time I spent I was unable to make it work. -- 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-17053) Distributed search: if all shards fail, fail the request despite shards.tolerant
[ https://issues.apache.org/jira/browse/SOLR-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794464#comment-17794464 ] ASF subversion and git services commented on SOLR-17053: Commit 5f67d4aed35b18e48bb43b5e1b583529b96211f8 in solr's branch refs/heads/main from aparnasuresh85 [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5f67d4aed35 ] SOLR-17053: Address ClassCastException issue (#2123) > Distributed search: if all shards fail, fail the request despite > shards.tolerant > > > Key: SOLR-17053 > URL: https://issues.apache.org/jira/browse/SOLR-17053 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 8.6 >Reporter: Aparna Suresh >Priority: Minor > Fix For: 9.5 > > Time Spent: 2h > Remaining Estimate: 0h > > If the request is tolerant to errors, logic in SearchHandler simply sets > partialResults to true upon detecting an error in ShardResponse. This means a > failure to query any shard would be reported back as partialResults=true, > instead of a query failure. > Why: Improve the error handling and reporting in the search system by making > sure that query failures are distinct from partial results -- 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-17053: Address ClassCastException issue [solr]
tflobbe merged PR #2123: URL: https://github.com/apache/solr/pull/2123 -- 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-16880: Add OAS to 'assembleRelease' task [solr]
gerlowskija commented on PR #2125: URL: https://github.com/apache/solr/pull/2125#issuecomment-1846143185 Alright, worked through the signing issues with some help (Thanks @HoustonPutman !). This should be functional and ready to go, assuming it's the route we want to take. -- 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-17053: Address ClassCastException issue [solr]
aparnasuresh85 commented on code in PR #2123:
URL: https://github.com/apache/solr/pull/2123#discussion_r1419683737
##
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java:
##
@@ -663,6 +659,15 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ public static void throwSolrException(Throwable shardResponseException)
throws SolrException {
Review Comment:
Missed on reviewing the change myself. Updated to private.
--
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] SOLR-17096: Cluster Singleton plugin support for immutable deployments [solr]
pjmcarthur opened a new pull request, #2126: URL: https://github.com/apache/solr/pull/2126 https://issues.apache.org/jira/browse/SOLR-17096 # Description It should be possible to install and manage the configuration of a cluster singleton plugin in an immutable deployment of SolrCloud. Currently, the only method to manage cluster singleton plugin configs is by using the `ContainerPluginApi` edit APIs, and this is not always possible, especially in the case of immutable SolrCloud deployments. # Solution This PR changes the `ContainerPluginRegistry` to use a pluggable source for plugin configs. The pluggable source is determined by a system propert, `solr.containerPluginsSource`, or by a declaration in solr.xml. The default source is `ZkContainerPluginsSource`, which allows plugins to be added, removed or updated at runtime using the `ContainerPluginApi`. This matches the existing behavior. A new OOTB plugin implementation is `NodeConfigContainerPluginsSource`. This plugin supports managing cluster singleton plugins via declarations in solr.xml, and does not support the edit APIs of `ContainerPluginApi`; these APIs are not registered in the case that node config is used as the plugin source. An example of solr.xml that supports cluster singleton declarations would be ``` ... ``` # Tests New tests are added in `NodeConfigContainerPluginsSourceTest` that spin up clusters and Core containers using the node config plugin source, and verify that cluster singleton declarations in solr.xml are added correctly to the `ContainerPluginsRegistry`. I have not updated any documentation (or CHANGES.txt) yet, pending comments here. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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-17053: Address ClassCastException issue [solr]
tflobbe commented on code in PR #2123:
URL: https://github.com/apache/solr/pull/2123#discussion_r1419671323
##
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java:
##
@@ -663,6 +659,15 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ public static void throwSolrException(Throwable shardResponseException)
throws SolrException {
Review Comment:
Any reason to make this `public`?
--
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-17053: Address ClassCastException issue [solr]
aparnasuresh85 commented on code in PR #2123:
URL: https://github.com/apache/solr/pull/2123#discussion_r1419532686
##
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java:
##
@@ -598,7 +598,7 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
boolean allShardsFailed = includesTopIdsPurpose &&
allResponsesHaveExceptions;
// if all shards fail, fail the request despite shards.tolerant
if (allShardsFailed) {
- throw (SolrException) srsp.getException();
+ throw new
SolrException(SolrException.ErrorCode.SERVER_ERROR, srsp.getException());
Review Comment:
I have addressed this in my recent commit
--
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] [Resolved] (SOLR-16835) Generate Python bindings from OpenAPI spec
[ https://issues.apache.org/jira/browse/SOLR-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-16835. Fix Version/s: main (10.0) 9.5 Resolution: Fixed Resolving this as it's been backported to 9.5 and doesn't seem to be causing any problems. Thanks to all for the feedback on the PR! > Generate Python bindings from OpenAPI spec > -- > > Key: SOLR-16835 > URL: https://issues.apache.org/jira/browse/SOLR-16835 > Project: Solr > Issue Type: New Feature > Components: v2 API >Affects Versions: main (10.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Labels: client > Fix For: main (10.0), 9.5 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > SOLR-16346 added support to Solr's build to generate an "OpenAPI spec" file > describing our v2 API. But currently, this spec file isn't actually used by > Solr in any way. > Spec files can be used for a variety of purposes, including to generate > client bindings in a variety of languages. > OpenAPI supports client-generation in many languages. Among these Python is > particularly promising due to the popularity of the language itself and of > the 3rd-party "pysolr" client. > (It's also an appealing starting-point from a development perspective, as > it's "green field" and therefore unconstrained by compatibility concerns as > the Java binding in SOLR-16825 is.) -- 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-16835) Generate Python bindings from OpenAPI spec
[ https://issues.apache.org/jira/browse/SOLR-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794377#comment-17794377 ] ASF subversion and git services commented on SOLR-16835: Commit 5eff6d0fb294eeb5b246d7387087d0269a55aa63 in solr's branch refs/heads/branch_9x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5eff6d0fb29 ] SOLR-16835: Generate Python client from OpenAPI spec (#1681) This commit adds build code to generate a Python client (using the OpenAPI Generator's 'python' template) and adds the necessary plumbing to bundle the client into an example directory used in Solr's LTR module. Note that nothing in this commit adds this client as a release artifact, publishes it to pip, etc. > Generate Python bindings from OpenAPI spec > -- > > Key: SOLR-16835 > URL: https://issues.apache.org/jira/browse/SOLR-16835 > Project: Solr > Issue Type: New Feature > Components: v2 API >Affects Versions: main (10.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Labels: client > Time Spent: 5h 50m > Remaining Estimate: 0h > > SOLR-16346 added support to Solr's build to generate an "OpenAPI spec" file > describing our v2 API. But currently, this spec file isn't actually used by > Solr in any way. > Spec files can be used for a variety of purposes, including to generate > client bindings in a variety of languages. > OpenAPI supports client-generation in many languages. Among these Python is > particularly promising due to the popularity of the language itself and of > the 3rd-party "pysolr" client. > (It's also an appealing starting-point from a development perspective, as > it's "green field" and therefore unconstrained by compatibility concerns as > the Java binding in SOLR-16825 is.) -- 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-13748: Add support for mm parameter to bool query parser [solr]
mkhludnev commented on PR #2025: URL: https://github.com/apache/solr/pull/2025#issuecomment-1845865301 @AndreyBozhko wdyt abt my changes? -- 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-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794375#comment-17794375 ] Jason Gerlowski commented on SOLR-16880: I've uploaded a [draft PR| https://github.com/apache/solr/pull/2125] that modifies our 'distribution' module to checksum the OAS and include it as a release artifact. It still needs some work, but it can serve as a base if we end up reaching consensus on this as an approach. > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > Time Spent: 20m > Remaining Estimate: 0h > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794374#comment-17794374 ] Jason Gerlowski commented on SOLR-16880: I'd definitely like to see Solr get a SwaggerUI (or something similar - some alternatives like redocly are pretty cool), but IMO it's not a sufficient replacement for exposing the OAS as a proper artifact. SwaggerUI wouldn't offer any of the checksum/signing niceties we would get with a proper release artifact. It also doesn't provide any easy way to lookup the spec for past releases - making it a pain to diff across multiple Solr versions, or detect breaking changes prior to a release. It requires that users stand up a Solr server to get the JSON file, etc. > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > Time Spent: 20m > Remaining Estimate: 0h > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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] [Comment Edited] (SOLR-13748) mm (min should match) param for {!bool} query parser
[
https://issues.apache.org/jira/browse/SOLR-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794331#comment-17794331
]
Mikhail Khludnev edited comment on SOLR-13748 at 12/7/23 5:07 PM:
--
Shouldn't we support all dismax mm syntax (with default 0)? It seems fancy, but
is there a need in it?
was (Author: mkhludnev):
Shouldn't we support all dismax mm syntax (with default 0). It seems fancy, but
is there a need in it?
> mm (min should match) param for {!bool} query parser
>
>
> Key: SOLR-13748
> URL: https://issues.apache.org/jira/browse/SOLR-13748
> Project: Solr
> Issue Type: Sub-task
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Time Spent: 1h 40m
> 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-13748) mm (min should match) param for {!bool} query parser
[
https://issues.apache.org/jira/browse/SOLR-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794331#comment-17794331
]
Mikhail Khludnev commented on SOLR-13748:
-
Shouldn't we support all dismax mm syntax (with default 0). It seems fancy, but
is there a need in it?
> mm (min should match) param for {!bool} query parser
>
>
> Key: SOLR-13748
> URL: https://issues.apache.org/jira/browse/SOLR-13748
> Project: Solr
> Issue Type: Sub-task
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Time Spent: 1h 40m
> 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
Re: [PR] SOLR-16880: Add OAS to 'assembleRelease' task [solr]
gerlowskija commented on PR #2125: URL: https://github.com/apache/solr/pull/2125#issuecomment-1845554961 One TODO remaining, if we choose to go this route, is to produce an "*.asc" signature for the OAS file. The PR currently contains some logic that tries to do this, but it's still not working for whatever reason. Something to work through at some point... -- 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] SOLR-16880: Add OAS to 'assembleRelease' task [solr]
gerlowskija opened a new pull request, #2125:
URL: https://github.com/apache/solr/pull/2125
This adds our OAS to the release artifacts gathered by the 'assembleRelease'
task in gradle. It produces a checksum for the OAS file and stores the file in
a separate 'oas' directory (similar to the 'changes' directory which already
exists for Changes.html).
One remaining piece here is signing - this commit attempts to produce an
'*.asc' signature for the OAS when signing is enabled, but doesn't quite have
it working yet.
https://issues.apache.org/jira/browse/SOLR-16880
# Description
Solr has, for some time, produced an OpenAPI spec ("OAS") describing its v2
APIs that it uses to (e.g.) generate Solr clients in various languages. But
while it uses the file internally, Solr doesn't (yet) expose the file to users
who may wish to do similar things.
# Solution
This PR proposes that we publish our openapi spec as a release artifact akin
to the various Changes.html files that we also put in artifacts.apache.org. It
does this by modifying the gradle tasks (esp. 'assembleRelease') in the
'distribution' gradle module.
# Tests
Manual testing via the `buildAndPushRelease.py` script and the smoke tester.
# Checklist
Please review the following and check all that apply:
- [x] I have reviewed the guidelines for [How to
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms
to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request
title.
- [x] I have given Solr maintainers
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the `main` branch.
- [ ] I have run `./gradlew check`.
- [ ] I have added documentation for the [Reference
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
--
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-17100) Publish generated Python and JS clients
[ https://issues.apache.org/jira/browse/SOLR-17100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794279#comment-17794279 ] Jan Høydahl commented on SOLR-17100: [https://packaging.python.org/en/latest/tutorials/packaging-projects/] gives a tutorial for pushing a package... > Publish generated Python and JS clients > --- > > Key: SOLR-17100 > URL: https://issues.apache.org/jira/browse/SOLR-17100 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - js, clients - python, v2 API >Reporter: Jason Gerlowski >Priority: Major > Labels: V2, client, release > > SOLR-16835 and SOLR-17062 gave us the ability to generate Python and > JavaScript clients from as a part of the Solr build. But while these clients > are used in small ways for dog-fooding (e.g. in the Admin UI), we aren't yet > publishing them in any way to make them available to users. > We should decide on a format for publishing these clients (a source code TGZ, > pip/npm packages, something else?), and modify our release process to make > both the JS and Python clients available in that format. -- 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-17100) Publish generated Python and JS clients
[
https://issues.apache.org/jira/browse/SOLR-17100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794259#comment-17794259
]
Jan Høydahl commented on SOLR-17100:
Yea, agree if we want end users to give it a spin, then {{pip install}} is the
ultimate way to go. But then we also risk putting off users that casually
search PyPi for solr client and they get a sub-par experience of it if it is
buggy and not well documented, acompanied by some blog post etc. So perhaps the
approach of separate tarball release is a middle ground. It will trigger more
use without a full formal release in the py community. Users would
# Read about the client somewhere
# Download solr-python-client-9.5.0.tgz from cdn
# Untar and copy as a folder in their source code
Yet another option is for one of the committers to publish with her private
account a "solr-client-experimental" package to PyPi, so the name clearly
indicates that this is a prerelease, and then encourage users to try it out?
Then the PMC can figure out how to publish an official one further down the
road, which probably also will include the tarball release.
> Publish generated Python and JS clients
> ---
>
> Key: SOLR-17100
> URL: https://issues.apache.org/jira/browse/SOLR-17100
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - js, clients - python, v2 API
>Reporter: Jason Gerlowski
>Priority: Major
> Labels: V2, client, release
>
> SOLR-16835 and SOLR-17062 gave us the ability to generate Python and
> JavaScript clients from as a part of the Solr build. But while these clients
> are used in small ways for dog-fooding (e.g. in the Admin UI), we aren't yet
> publishing them in any way to make them available to users.
> We should decide on a format for publishing these clients (a source code TGZ,
> pip/npm packages, something else?), and modify our release process to make
> both the JS and Python clients available in that format.
--
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-17100) Publish generated Python and JS clients
[ https://issues.apache.org/jira/browse/SOLR-17100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794205#comment-17794205 ] Jason Gerlowski commented on SOLR-17100: I wouldn't use the term "rush", but IMO there's value in getting an official (albeit experimental) release of these clients out there. Ultimately, I'm skeptical that the feedback we need is going to come with the current approach. I've been soliciting it for at least 6 months now, without much success. (see [JIRA|https://issues.apache.org/jira/browse/SOLR-16835?focusedCommentId=17728970&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17728970], [Github|https://github.com/apache/solr/pull/1681#issuecomment-1573892626], the [users list|https://lists.apache.org/thread/tstf1xlyw7xlmfqnv7dtl23s2mlqd2mr], [conference talks|https://www.youtube.com/watch?v=SOf28pyZVI0], our "virtual community meetups", etc.). If we want feedback we need to make accessing these clients as easy and familiar as possible. We're pretty far from that today. Right now, a user interested in trying the Python client would have to: # Find and clone Solr's source code # Figure out what branch or tag to navigate to based on their Solr version # Install the prerequisites (e.g. Java) for running the gradle build (which they may be completely unfamiliar with) # Run a gradle command to generate the source code they _actually_ care about # Run a separate Python command to install that code into their environment. Those steps might not sound intimidating to devs experienced with and invested in the project. But it's more than enough to turn away anyone with more casual interest. An official-but-experimental release lets us flatten this all down to a single "pip install" command and (hopefully) get more feedback as a result. Is there a reason to _avoid_ publishing these as experimental artifacts? > Publish generated Python and JS clients > --- > > Key: SOLR-17100 > URL: https://issues.apache.org/jira/browse/SOLR-17100 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - js, clients - python, v2 API >Reporter: Jason Gerlowski >Priority: Major > Labels: V2, client, release > > SOLR-16835 and SOLR-17062 gave us the ability to generate Python and > JavaScript clients from as a part of the Solr build. But while these clients > are used in small ways for dog-fooding (e.g. in the Admin UI), we aren't yet > publishing them in any way to make them available to users. > We should decide on a format for publishing these clients (a source code TGZ, > pip/npm packages, something else?), and modify our release process to make > both the JS and Python clients available in that format. -- 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] Add config & logic to control how updates are collapsed in the Consumer. [solr-sandbox]
sigram opened a new pull request, #97: URL: https://github.com/apache/solr-sandbox/pull/97 (no comment) -- 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] [experimental] TextToVectorProcessor(Factory) using ONNX via OpenNLP [solr]
cpoerschke commented on code in PR #2120:
URL: https://github.com/apache/solr/pull/2120#discussion_r1418801345
##
gradle/testing/randomization/policies/solr-tests.policy:
##
@@ -100,6 +100,9 @@ grant {
permission java.lang.RuntimePermission "loadLibrary.jaas";
permission java.lang.RuntimePermission "loadLibrary.jaas_unix";
permission java.lang.RuntimePermission "loadLibrary.jaas_nt";
+ // needed by ONNX integration (TODO: there is a cleaner way to handle this)
+ permission java.lang.RuntimePermission "loadLibrary.*"; // TODO: make more
specific
+ permission java.io.FilePermission
"/Users/cpoerschke/opennlp-data/onnx/sentence-transformers/vocab.txt", "read";
// TODO: remove when no longer used
Review Comment:
I'd love to see the "films" [vector
model](https://github.com/apache/solr/tree/main/solr/example/films/vectors) as
convertible to ONNX and then we could use it e.g. for tests. But not yet looked
into details much.
##
gradle/testing/randomization/policies/solr-tests.policy:
##
@@ -100,6 +100,9 @@ grant {
permission java.lang.RuntimePermission "loadLibrary.jaas";
permission java.lang.RuntimePermission "loadLibrary.jaas_unix";
permission java.lang.RuntimePermission "loadLibrary.jaas_nt";
+ // needed by ONNX integration (TODO: there is a cleaner way to handle this)
+ permission java.lang.RuntimePermission "loadLibrary.*"; // TODO: make more
specific
Review Comment:
above there's `${common.dir}` and `${common-solr.dir}` usage and i imagine
some property usage here could avoid the top-level wildcard use, but not yet
looked into details; illustration:
```suggestion
permission java.lang.RuntimePermission
"loadLibrary.${someBuildDirectory}/*";
```
--
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/example/films/vectors/README.md tweaks [solr]
cpoerschke merged PR #2121: URL: https://github.com/apache/solr/pull/2121 -- 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-15484 JWTAuthPluginIntegrationTest - dynamically generate the self-signed certificate using the localhost loopback address [solr]
janhoy commented on code in PR #2099:
URL: https://github.com/apache/solr/pull/2099#discussion_r1418743711
##
solr/modules/jwt-auth/src/test/org/apache/solr/security/jwt/KeystoreGenerator.java:
##
@@ -0,0 +1,116 @@
+/*
+ * 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.jwt;
+
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.math.BigInteger;
+import java.nio.file.Path;
+import java.security.KeyPair;
+import java.security.KeyPairGenerator;
+import java.security.KeyStore;
+import java.security.KeyStoreException;
+import java.security.NoSuchAlgorithmException;
+import java.security.Provider;
+import java.security.Security;
+import java.security.cert.CertificateException;
+import java.security.cert.X509Certificate;
+import java.time.Instant;
+import java.time.LocalDate;
+import java.time.ZoneOffset;
+import java.time.ZonedDateTime;
+import java.util.Date;
+import org.bouncycastle.asn1.DERUTF8String;
+import org.bouncycastle.asn1.x500.AttributeTypeAndValue;
+import org.bouncycastle.asn1.x500.RDN;
+import org.bouncycastle.asn1.x500.X500Name;
+import org.bouncycastle.asn1.x500.style.BCStyle;
+import org.bouncycastle.asn1.x509.BasicConstraints;
+import org.bouncycastle.asn1.x509.Extension;
+import org.bouncycastle.cert.CertIOException;
+import org.bouncycastle.cert.jcajce.JcaX509CertificateConverter;
+import org.bouncycastle.cert.jcajce.JcaX509v3CertificateBuilder;
+import org.bouncycastle.jce.provider.BouncyCastleProvider;
+import org.bouncycastle.operator.ContentSigner;
+import org.bouncycastle.operator.OperatorCreationException;
+import org.bouncycastle.operator.jcajce.JcaContentSignerBuilder;
+
+public class KeystoreGenerator {
+
+ private static final String PASS_PHRASE = "secret";
+
+ public void generateKeystore(Path existingKeystore, Path newKeystore, String
cn) {
Review Comment:
@jdyer1 We may be able to simplify this PR by using mock-oauth2-server's
[new SSL
capability,](https://github.com/navikt/mock-oauth2-server#enabling-https) which
includes ssl cert auto creation. So if we find a way to detect the correct
local hostname to use in the cert, we can initialize the mock-server with this
code:
```java
String myHostname = "localhost";
Ssl selfSignedSslLocalhost =
new Ssl(new SslKeystore("",
SslKeystore.Companion.generate(myHostname, "")));
OAuth2Config config =
new OAuth2Config(
false,
null,
new OAuth2TokenProvider(),
Collections.emptySet(),
new MockWebServerWrapper(selfSignedSslLocalhost));
MockOAuth2Server mockOAuth2Server = new MockOAuth2Server(config);
```
--
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] [Comment Edited] (SOLR-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794109#comment-17794109 ] Jan Høydahl edited comment on SOLR-16880 at 12/7/23 10:08 AM: -- Have you considered adding a SwaggerUI servlet to Solr (e.g. one that serves the apiDoc on [http://localhost:8983/api])? It can be unprotected, as it is just a web page generated from the OAS. !Skjermbilde 2023-12-07 kl. 11.01.57.png|width=800! The page would allow interactive testing of APIs directly on the server, and also allow download of the spec file. Test: https://app.swaggerhub.com/apis-docs/JanHydahl/v-2_api/10.0.0 was (Author: janhoy): Have you considered adding a SwaggerUI servlet to Solr (e.g. one that serves the apiDoc on [http://localhost:8983/api])? It can be unprotected, as it is just a web page generated from the OAS. [https://app.swaggerhub.com/apis-docs/JanHydahl/v-2_api/10.0.0] !Skjermbilde 2023-12-07 kl. 11.01.57.png|width=800! > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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] [Comment Edited] (SOLR-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794109#comment-17794109 ] Jan Høydahl edited comment on SOLR-16880 at 12/7/23 10:03 AM: -- Have you considered adding a SwaggerUI servlet to Solr (e.g. one that serves the apiDoc on [http://localhost:8983/api])? It can be unprotected, as it is just a web page generated from the OAS. [https://app.swaggerhub.com/apis-docs/JanHydahl/v-2_api/10.0.0] !Skjermbilde 2023-12-07 kl. 11.01.57.png|width=800! was (Author: janhoy): Have you considered adding a SwaggerUI servlet to Solr (e.g. one that serves the apiDoc on [http://localhost:8983/api])? It can be unprotected, as it is just a web page generated from the OAS. !Skjermbilde 2023-12-07 kl. 11.01.57.png|width=800! > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794109#comment-17794109 ] Jan Høydahl commented on SOLR-16880: Have you considered adding a SwaggerUI servlet to Solr (e.g. one that serves the apiDoc on [http://localhost:8983/api])? It can be unprotected, as it is just a web page generated from the OAS. !Skjermbilde 2023-12-07 kl. 11.01.57.png|width=800! > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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-16880) Make OpenAPI spec a release artifact
[ https://issues.apache.org/jira/browse/SOLR-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-16880: --- Attachment: Skjermbilde 2023-12-07 kl. 11.01.57.png > Make OpenAPI spec a release artifact > > > Key: SOLR-16880 > URL: https://issues.apache.org/jira/browse/SOLR-16880 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Attachments: Skjermbilde 2023-12-07 kl. 11.01.57.png > > > SOLR-16346 added OpenAPI spec generation to Solr - allowing us to produce a > detailed description of our v2 APIs (or at least - those APIs implemented > using JAX-RS). > These spec files have a lot of potential uses - from generating > documentation, to API clients, to web UIs. These have a lot of promise, but > it will take the community time to implement and adopt some of them. > We should make the OpenAPI spec available as a release artifact, so that > users can more easily take advantage of it. Having it published on each > release will also allow us to compare specs across versions, as a way to > detect backcompat breaks before changes go out the door. -- 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
