[
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: [email protected]
For additional commands, e-mail: [email protected]
