[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643380#comment-17643380
]
Jason Gerlowski edited comment on SOLR-16347 at 12/5/22 3:03 PM:
-----------------------------------------------------------------
bq. I'm still awaiting [...]
Quick reminder that this is a volunteer community. Not everyone has personal
situations that allow them to reply on weekends, or within 24 hours, or
whatever. I try my best to send out quick replies, but two days is not an
unreasonable response time - especially when it spans a weekend.
But sure - to clarify I wasn't "alleging" anything intentional; just pointing
out that as helpful as you were in laying out the full context on
SOLR-16531....not everyone reading this JIRA has necessarily read that one.
Making simplified claims like "33% slower" that depend on or assume context
from some other thread is going to leave some readers in the dark about the
full picture. Not everyone "clicks through" on footnote-links :P
In terms of the veto, if you're *not* open to a compromise that'd hopefully
address both our concerns, then I guess I'll need to decide whether or not to
raise the issue with the PMC to determine whether there's "valid technical
justification" for the veto.
I'm personally not convinced there is. (If I was convinced I would've just
"done the thing" long ago.). I sympathize that you two don't believe there's a
path forward, and that you're dissatisfied with the progress so far - but those
aren't exactly technical justifications. They're personal beliefs and
expectations (that reasonable people can differ on). The only concrete,
technical aspects of this discussion (i.e. the slowdown itself) have relatively
simple workarounds that don't require a complex revert (i.e.
{{-Ddisable.v2.api}} with the [fix|https://github.com/apache/solr/pull/1210] I
suggested last week).
Not that I'll necessarily go the PMC route. Still weighing which option will
be less hassle and distraction, and get everyone back to "actual work" (like
actually addressing the perf here) soonest.
was (Author: gerlowskija):
Sure - to clarify I wasn't "alleging" anything intentional; just pointing out
that as helpful as you were in laying out the full context on SOLR-16531....not
everyone reading this JIRA has necessarily read that one. Making simplified
claims like "33% slower" that depend on or assume context from some other
thread is going to leave some readers in the dark about the full picture. Not
everyone "clicks through" on footnote-links :P
In terms of the veto, if you're *not* open to a compromise that'd hopefully
address both our concerns, then I guess I'll need to decide whether or not to
raise the issue with the PMC to determine whether there's "valid technical
justification" for the veto.
I'm personally not convinced there is. (If I was convinced I would've just
"done the thing" long ago.). I sympathize that you two don't believe there's a
path forward, and that you're dissatisfied with the progress so far - but those
aren't exactly technical justifications. They're personal beliefs and
expectations (that reasonable people can differ on). The only concrete,
technical aspects of this discussion (i.e. the slowdown itself) have relatively
simple workarounds that don't require a complex revert (i.e.
{{-Ddisable.v2.api}} with the [fix|https://github.com/apache/solr/pull/1210] I
suggested last week).
Not that I'll necessarily go the PMC route. Still weighing which option will
be less hassle and distraction, and get everyone back to "actual work" (like
actually addressing the perf here) soonest.
> 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
