[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086726#comment-14086726
]
Steve Rowe commented on SOLR-6191:
----------------------------------
Nice idea, [~noble.paul], a couple questions:
# You imply by naming the outer annotation {{Method}} that it will always be
applied to classes that serve as REST(-like) endpoints, but that won't be true
for components; I guess since {{Method.path}} defaults to empty it could be
ignored by components, but maybe we should have another container annotation
like {{Params}} to hold multiple {{Param}} annotations when the class doesn't
need a {{path}}?
# Handlers can be respond to multiple endpoints, which is configured in
{{solrconfig.xml}}, rather than at compile-time; how do you think this should
be handled?
# I think whatever solution we land on, it should be possible to fully describe
parameters in a single place. Will annotations suffice to handle all
param-related functionality? E.g. when initializing and testing
handlers/components, will annotations provide a clean interface to pull named
parameters out? (Your patch doesn't illustrate this at all.)
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---------------------------------------------------------------
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
> Reporter: Vitaliy Zhovtyuk
> Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
