[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17586116#comment-17586116
]
Jason Gerlowski commented on SOLR-16347:
----------------------------------------
Alright, a progress update for the week:
* Use of the plugin framework "just works" at the core-level, since core-level
plugins rely on code in PluginBag that the PR is already integrated with.
* Cluster/Container-level plugins are a bit of a different story: these are
loaded in a special ContainerPluginRegistry class that eschews the PluginBag
abstraction that's used most other places to register and load
handlers/apis/endpoints. It looks like that was an intentional decision, as
ContainerPluginRegistry explicitly _doesn't_ support RequestHandlers and is
currently pretty specific to the 'Api' interface.
** Of course, we can change this all: either by adding separate codepaths in
ContainerPluginRegistry for 'JerseyResource' instances, or maybe by having
JerseyResource actually extend/implement Api in some way?
** But for now it seems reasonable to defer this, as it'd require conceptual
changes to the plugin framework that deserve their own JIRA/discussion.
* I've improved the v2 response-POJO processing a bit so that structured
response objects can be converted to the maps/NamedLists expected by v1 code,
without needing the homegrown "JsonProperty" mimic we used as an aid for
reflection previously.
* PR has metrics support, based loosely on the code in RequestHandlerBase but
implemented as Jersey pre- and post request filters.
** Currently, V2 Jersey requests produce the same metrics as their v1
counterparts (as long as there _is_ a corresponding v1 API). I'm not sure if
that's good or not: the v2 API could conceivably produce more granular metrics
since it by-design has fewer of the endpoints that support a bazillion
different commands. But that seems like a larger discussion, hopefully driven
by someone with a better appreciation for how users make use of these metrics
in practice.
* PR now uses a Jersey exception mapper to produce the same error format as
most Solr APIs.
* I've done most (but not all) of the memory-footprint/perf sanity-checking
that I mentioned above.
Overall things are starting to come together. At this point I plan on turning
my attention next week to adding and running tests, addressing the few
remaining TODOs, and general PR cleanup. I'd love some additional feedback on
the PR if anyone has a mind. But if I don't hear much on the review front and
I can get tests and cleanup squared away, I'd love to get the first round of
this committed late next week (or the week after) and start moving over APIs.
If we can get this and the OpenAPI integration merged (SOLR-16346) merged, we
could have partial, experimental auto-generated clients in one or two minor
release's time. Exciting!
> 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
>
> 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]
