[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643475#comment-17643475
]
Houston Putman commented on SOLR-16347:
---------------------------------------
bq. If you plan to disable by default an API endpoint (that works as of 9.1
release), I'll have to veto that as well.
I don't think anyone is suggesting that. The PR is to make that flag a
workaround so that other performance testing can occur concurrently while this
is being addressed. No one is going to disable v2 by default.
bq. I am appalled at your under-estimation of the intellectual capabilities of
some of those readers that you talk about.
Ok everyone, let's slow down here. This is how things get blown out of
proportion. Ishan, you did provide a link to more documentation around this.
Jason, you would like more explanation inline (less editorialization). Neither
of you have done anything wrong. Let's end it there.
bq. I am a committer and PMC member and I'm invoking my right to veto these
commits. As per ASF guidelines, a vetoed commit must be reverted, preferably by
the original committer. Feel free to discuss this in any forum you feel
appropriate.
You do have this right, but I hope you understand it is a hostile move. Jason
has said that this performance regression is his top priority. I have also said
that this patch will not be in 9.2 if the performance regression is not fixed
at that point. He is trying to address your other concern (not being able to do
other performance tests in the meantime) by adding that flag mentioned above.
I understand that there has been a good amount of time since this was first
reported, but life happens, and this code was committed at the perfect time to
give it a while to be tested and fixed.
Instead of forcing the revert, can we set a deadline by which this performance
regression should be addressed? If it's fixed by that date we are all in a much
better position. If it's not fixed, we can start reverting this from 9x.
I seriously doubt we are going to release 9.2 before February, *so I think a
reasonable deadline would be January 11th*. That gives us plenty of time to try
to fix this, but also plenty of time to do the revert if it is necessary. And
we can start a 9.2 release if we want to by late January/early February.
> Add JAX-RS integration for defining v2 APIs
> -------------------------------------------
>
> Key: SOLR-16347
> URL: https://issues.apache.org/jira/browse/SOLR-16347
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> SOLR-15182 rewrote our v2 APIs to use annotations using an existing
> (in-house) framework. But continuing to use a homegrown framework is less
> than ideal for a few reasons:
> # Our in-house framework doesn't integrate with 3rd-party tooling like
> OpenAPI.
> # It gives us less functionality than many off-the-shelf frameworks, at a
> higher maintenance cost.
> # The current framework is less explicit about API inputs and outputs than
> many off-the-shelf alternatives, making code less clear and readable for
> developers.
> (For more on the pros/cons and for different evaluations on the tradeoff
> here, see
> [this|https://lists.apache.org/thread/6wx2vzfnmfgkw03b7s450zfp7yhrlz8f]
> long-running dev@ thread.)
> The work done by SOLR-15182 makes the jump to JAX-RS reasonably
> straightforward on an individual API basis: once the framework is in place
> switching a given API to JAX-RS is mostly a matter of swapping out our
> homegrown annotations for those recognized by JAX-RS and changing API method
> signatures to better represent the API inputs/outputs.
> We should integrate Jersey or a similar JAX-RS implementation and start
> cutting over v2 APIs to this new mode of definition.
--
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
