[
https://issues.apache.org/jira/browse/SOLR-16461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619003#comment-17619003
]
Jason Gerlowski commented on SOLR-16461:
----------------------------------------
Hi [~duttsanjay] - thanks for trying out the JAX-RS/Jersey route!
Why don't you try pushing a PR with what you have so far? (You can mark it as
a "draft" in Github, to communicate that it's not totally ready yet.). Getting
all of your code up there is the easiest way give everyone else the "whole
picture" that they'd need to help you out.
bq. I am not sure yet whether we can inject ReplicationHandler directly into
the constructor not(I guess we cannot).
As things stand today, you're right. There's two main reasons for that: one
mechanical and one more "strategic" I guess.
Mechanically: well, Solr has a lot of request handlers, and integrating each of
them in with JAX-RS/Jersey in a way that'd allow them to be injected is a bit
prohibitive.
Strategically...A lot of our "traditional" v2 APIs take in the RequestHandler
they need and are largely a sort of wrapper around that, but we decided to go a
different direction with our JAX-RS/Jersey-based APIs and have them be the
"home" for the actual functionality and logic underlying the APIs. i.e. they
shouldn't "just" call the RequestHandler. Mostly for the three reasons below:
* moving logic out of the v1-centered RequestHandlers puts us on better footing
to eventually deprecate the RequestHandler classes themselves as v2 becomes
more widely used.
* JAX-RS/Jersey API implementations allow stronger typing than was available in
RequestHandler logic, where parameters mostly come in as loosely-typed maps.
* RequestHandlers tend to be massive classes that cover anywhere from 5 to 30
distinct APIs. Splitting the logic up makes the code more maintainable going
forward.
(There's been past discussions on each of those points, I'll try to dig up the
links for context if anyone's curious and I get a few minutes.)
Of course, that makes writing these JAX-RS/Jersey APIs a bit harder than the
traditional approach, as it requires devs to integrate the API implementation
into the API class, instead of it being largely a matter of reformatting inputs
and calling a RequestHandler method. But the hope is that it's worth the extra
effort.
bq. I have tried only with SolrQueryRequest and SolrQueryResponse but it's
still throwing error.
The code you shared above looks great to me (aside from the ReplicationHandler
injection). Not sure why you're seeing errors. But if you can get your draft
PR posted I'm happy to help review and hopefully we can sort it out!
> Create v2 equivalent of v1 'BACKUP' (A backup API for user managed cluster or
> single node installation)
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16461
> URL: https://issues.apache.org/jira/browse/SOLR-16461
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Affects Versions: 9.1
> Reporter: Sanjay Dutt
> Priority: Major
> Labels: V2
>
> A backup API for user manager cluster or single node installation has no v2
> equivalent. This ticket is used to track changes that will be made to add the
> v2 API for the 'backup'.
>
>
>
--
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
