[ 
https://issues.apache.org/jira/browse/SOLR-14437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096141#comment-17096141
 ] 

Noble Paul commented on SOLR-14437:
-----------------------------------

we can remove the methods
{code}
  default Boolean registerV1() { return Boolean.TRUE; }
  default Boolean registerV2() { return Boolean.FALSE; }
{code}

can you explain a bit more on the {{getApis()}} ?

> Remove/refactor "ApiSupport" interface? (for V2 API)
> ----------------------------------------------------
>
>                 Key: SOLR-14437
>                 URL: https://issues.apache.org/jira/browse/SOLR-14437
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: v2 API
>    Affects Versions: master (9.0)
>            Reporter: David Smiley
>            Priority: Major
>
> ApiSupport.java is an interface relating to the V2 API that is implemented by 
> all request handlers, both those at a core level and others.  It's 
> essentially this: (comments removed)
> {code:java}
> public interface ApiSupport {
>   Collection<Api> getApis();
>   default Boolean registerV1() { return Boolean.TRUE; }
>   default Boolean registerV2() { return Boolean.FALSE; }
> }
> {code}
> Firstly, let's always assume that the handler will always be registered in 
> V2.  All implementations I've seen explicitly return true here; maybe I'm 
> missing something though.
> Secondly, getApis() seems problematic for the ability to lazily load request 
> handlers.  Can we assume, at least for core level request handlers, that 
> there is exactly one API and where necessary rely on the "spec" JSON 
> definition -- see org.apache.solr.api.ApiBag#registerLazy ?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to