thelabdude opened a new pull request #1938: URL: https://github.com/apache/lucene-solr/pull/1938
<!-- _(If you are a project committer then you may remove some/all of the following template.)_ Before creating a pull request, please file an issue in the ASF Jira system for Lucene or Solr: * https://issues.apache.org/jira/projects/LUCENE * https://issues.apache.org/jira/projects/SOLR You will need to create an account in Jira in order to create an issue. The title of the PR should reference the Jira issue number in the form: * LUCENE-####: <short description of problem or changes> * SOLR-####: <short description of problem or changes> LUCENE and SOLR must be fully capitalized. A short description helps people scanning pull requests for items they can work on. Properly referencing the issue in the title ensures that Jira is correctly updated with code review comments and commits. --> # Description Here’s a quick pass at keeping the existing ManagedResource API endpoints in place but without using Restlet. Now that I’ve gone through this code again, it seems like Restlet was more aspirational than technically required to support the current functionality. As I said on the mailing list, I don’t know the history of why Restlet was introduced so I can’t say much more about that. What I do know is that it’s not needed to support the ManagedResource endpoints we have today. In a nutshell, RestManager keeps a mapping from a PATH (e.g. /schema/analysis/stopwords/english) to a ManagedResource impl and Restlet is used to route REST requests for the PATH to a ManagedResource. There’s a ManagedEndpoint used as the shim between Restlet and the ManagedResource that’s just details ... In this PR, I’ve simply replaced the Restlet routing logic with a SolrRequestHandler that resolves the ManagedResource for a PATH using the RestManager’s mapping. Put simply, plugging into the Restlet routing logic isn’t necessary for Managed Resources. Not to mention, there’s some rigid mapping to /schema in places, so I’m not certain we achieved the supposed goal of supporting dynamic mapping of path to resource that Restlet provides. As has been discussed on the mailing list, we could just remove all of this ManagedResource code from master but that requires us to come up with some LTR specific request handler to allow managing models and features. However, the approach in this PR doesn’t feel too dirty to me and avoids breaking the existing APIs for stopwords / synonyms / LTR models & features. I’m happy to go either way here but wanted to see what it would take to remove Restlet but keep the existing endpoints and this work accomplishes that. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
