You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2021/06/19 00:26:00 UTC
[jira] [Comment Edited] (SOLR-15488) Unify package structure for v2
APIs
[ https://issues.apache.org/jira/browse/SOLR-15488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365824#comment-17365824 ]
Jason Gerlowski edited comment on SOLR-15488 at 6/19/21, 12:25 AM:
-------------------------------------------------------------------
I created a PR for this, but ran into one snag that's making me reconsider the idea entirely.
Most of the API classes I'd looked at previously were lightweight layers that remapped parameters before delegating out to whatever v1 handler contained the "real" logic. But there are a few API classes that contain the actual "meat" of the API. This isn't a problem in and of itself, but in several instances (particularly schema-designer) these API classes rely on package-private methods that are no longer visible when the API is moved into a sub "api" package. It's clear that the original authors put thought and intention into the visibility on these classes, so I don't want to take the easy way out and just blindly increase visibility in these cases.
This was never a hugely important refactor, so if no better ideas occur to me I'll probably close this out shortly as not worth the limited benefit. It was a good experiment at least.
was (Author: gerlowskija):
I created a PR for this, but ran into one snag that's making me reconsider the idea.
Most of the API classes I'd looked at previously were lightweight layers that remapped parameters before delegating out to whatever v1 handler contained the "real" logic. But there are a few API classes that contain the actual "meat" of the API. This isn't a problem in and of itself, but in several instances (particularly schema-designer) these API classes rely on package-private methods that are no longer visible when the API is moved into a sub "api" package. It's clear that the original authors put thought and intention into the visibility on these classes, so I don't want to take the easy way out and just blindly increase visibility in these cases.
This was never a hugely important refactor, so if no better ideas occur to me I'll probably close this out shortly as not worth the limited benefit.
> Unify package structure for v2 APIs
> -----------------------------------
>
> Key: SOLR-15488
> URL: https://issues.apache.org/jira/browse/SOLR-15488
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: main (9.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, V2 APIs are scattered throughout solr-core's package structure.
> Some live in feature-specific packages (e.g. {{PackageAPI}} in {{org.apache.solr.pkg}}). Some live alongside v1 "handler" code ({{ClusterAPI}} in {{org.apache.solr.handler}}), or in a feature specific package below that ({{ZookeeperReadAPI}} in {{org.apache.solr.handler.admin}}). Some (the most recently created), live in a package intended for v2 APIs within the "handler" package (e.g. {{AddReplicaPropertyAPI}} in {{org.apache.solr.handler.admin.api}}).
> We should decided on the best place(s) for these classes to live, and realign them accordingly so that the convention is clear for future work on the v2 APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org