[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611228#comment-17611228
]
Jason Gerlowski edited comment on SOLR-16347 at 9/29/22 8:32 PM:
-----------------------------------------------------------------
Thanks for the vote David!
I should probably summarize a short conversation I had with Ishan in
[Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1664302248555829?thread_ts=1664285145.742919&cid=CEKUCUNE9]:
bq. I felt the API changes was a big change that can potentially impact the
ease with which bug fixes can be ported to the 9.1 branch.
Which definitely makes some sense.
I think the sort of code this ticket touches (V2HttpCall, net-new Jersey
integration code, etc.) is unlikely to cause merge conflicts with any bugs
folks might be trying to rush back to branch_9_1, but you never know.
For now I think my plan is to hold off backporting to branch_9x. If that
becomes particularly painful for some reason, maybe I'll take the gamble and do
it. But hopefully there won't be too many merge-conflict issues by my waiting,
since, as I said it's mostly green-field code or changes in classes that are
touched pretty rarely.
was (Author: gerlowskija):
Thanks for the vote David!
I should probably summarize a short conversation I had with Ishan in
[Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1664302248555829?thread_ts=1664285145.742919&cid=CEKUCUNE9]:
bq. I felt the API changes was a big change that can potentially impact the
ease with which bug fixes can be ported to the 9.1 branch.
Which definitely makes some sense.
I think the sort of code this ticket touches (V2HttpCall, net-new Jersey
integration code, etc.) is unlikely to cause merge conflicts with any bugs
folks might be trying to rush back to branch_9_1, but you never know.
For now I think my plan is to hold off backporting to branch_9x, BUT if this
starts to block other work then I might take the slight risk on the branch_9x
backport.
> 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: 2h 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: [email protected]
For additional commands, e-mail: [email protected]
