jaykay12 commented on PR #5022:
URL: https://github.com/apache/solr/pull/5022#issuecomment-6096728903
> Thanks for explaining this to me.... With the final cutover being at the
end, it does mean that each of these PR's isn't a complete feature, in that
from an external perspective, we never actually exercise these new apis...
Which I suppose is fine as long as we make it to that final cut over!!!
>
> Does teh fact that we never exercise the new apis mean the screen shots
aren't actually meaningful? Because the v2 calls are just routed to the old v1
endpoint and returned right? Whcih is fine if our goal is to have java code
validation, and then do a cut over at the end??? Just want to make sure I am
underrstanding things....
Yeah, you’ve got the picture right.
One small nuance on “routed to the old v1 endpoint”: the
/api/.../config/overlay and /znodeVersion calls still come in on the V2 path
(V2HttpCall). What happens is ApiBag matches the existing AnnotatedApi wildcard
/config/{component} in GetConfigAPI before Jersey ever gets a look, so they go
AnnotatedApi → SolrConfigHandler.handleGET → GetConfig (via squash). They never
hit the Jersey-registered getOverlay() / getZnodeVersion() methods — which is
why your Accept: application/xml curl still comes back as JSON/200 instead of a
406.
So the screenshots are meaningful as a regression check that response bodies
stay equivalent after moving the logic into GetConfig, not as proof that Jersey
owns the route.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
