[
https://issues.apache.org/jira/browse/SOLR-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733543#comment-17733543
]
Jason Gerlowski commented on SOLR-16847:
----------------------------------------
One way I could envision this working:
# Each v2 API class that accepts solrconfig.xml config would have an
accompanying “Config” class (e.g. HealthcheckAPIConfig). This class would have
a constructor that takes in the same NamedList passed to v1 init() methods
today. The config class would be responsible for parsing that NL and allowing
access to whatever values it supports via getters.
# At API load/registration (i.e. on Solr startup or core-load), Solr would
create an instance of the Config class, and register it with Jersey as an
“injectable” singleton
# The API class itself would have an @Inject -annotated ctor which expects an
instance of the Config class.
# The API class can then use the config-class getters in its application logic.
> Give v2 APIs access to solrconfig.xml config
> --------------------------------------------
>
> Key: SOLR-16847
> URL: https://issues.apache.org/jira/browse/SOLR-16847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2
>
> Our v2 framework(s) still lack parity with our v1 RequestHandlers in one
> important area: configuration and initialization.
> v1 RequestHandlers have an {{init(NamedList)}} method which is called at
> creation time and allows RH's to handle any configuration attached to the
> relevant {{<requestHandler>}} tag in solrconfig.xml. This is most commonly
> used by administrators to override default values.
> We should add similar functionality to our JAX-RS framework. (It's also a
> gap in the homegrown annotation framework, but as we're moving away from this
> it's probably a much lower priority to add there).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
