[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603815#comment-17603815
]
Jason Gerlowski commented on SOLR-16347:
----------------------------------------
Hey [~krisden], thanks for the heads up. It was my mistake on introducing them
and I'll look as soon as I'm able. (I suspect some are things we'll need to
suppress or excuse in some way. I'm not sure why they're detected as "unused",
but I'm certain that at least 2 of these are in use).
Totally independent of that - I'm a little confused about how you noticed these
errors (and how/why I missed them).
When I run {{gradlew check}}, I can find the warnings you mentioned, but I have
to scroll up ~500 lines or so. And, what's more, {{gradlew check}} goes on to
succeed despite these warnings! Like everyone else (I thought?), I always run
{{gradlew check}} as my pre-commit sanity check; is there some other command I
should be adding to that routine? And/or do you know why {{check}} doesn't
fail out on these errors?
> 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
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
