epugh commented on PR #5022:
URL: https://github.com/apache/solr/pull/5022#issuecomment-6096599345
> Thanks for tracing this, Eric, and for the Accept: application/xml curl.
You are right that `/config/{component}` still matches overlay and
znodeVersion, so those requests stay on the AnnotatedApi path and Jersey is not
invoked. handleGET calls GetConfig, so the response still comes from the shared
implementation. The JAX-RS methods are what SolrJ and the OpenAPI spec see.
>
> That is intentional for this PR. The remaining `/config/{component}`
values are still on that wildcard, and one follow-up PRs for them are already
in flight & few more are planned. The last of those will remove
/config/{component}, the same way #4951 removed the old /config endpoint once
that path had moved. I will carry this note onto those PRs as well.
>
> On your third comment. I would rather leave the single wildcard in place
and do that cutover once, in the last follow-up, when nothing is left on
{component}.
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....
--
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]
