[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
-------------------------------
Attachment: SOLR-281-SearchComponents.patch
Yonik, i could not get your last patch to apply cleanly to trunk. This is my
best attempt to resolve the conflicts and fix a few things.
1. remove the call to getResponseBuilder() in SearchComponent
2. the timing info was commented out of debugging
- - - - -
The dismax changes look great - i like the new query parser stuff!
> - removed variable RequestBuilder class logic since it seems unnecessary...
> if two non-standard components want to communicate something, they can
> use the Context or the Response. (any reason I'm missing why it should stay?)
If at all possible, I think we should do our best to avoid depending on
Map<String> for an interface.
>
> We need to think through all the members of ResponseBuilder carefully and
> decide what component sets/reads them in what phase (and if that makes the
> most sense).
>
yes
>
> Should ResponseBuilder have methods instead of members? If so, that would
> allow a component to perhaps even replace the ResponseBuilder and delegate to
> the original.
>
yes, that makes sense. How would a component replace the ResponseBuilder? If
it could do that, there is obviously no need for the variable RequestBuilder
class logic
>
> How will a users custom component get configuration? Should components be a
> full plugins with an init() for configuration?
>
As is, they are defined in a "components" section for SearchHandler (from the
example solrconfig.xml):
<requestHandler name="/search" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
</lst>
<arr name="components">
<str>org.apache.solr.handler.component.QueryComponent</str>
<str>org.apache.solr.handler.component.FacetComponent</str>
<str>org.apache.solr.handler.component.MoreLikeThisComponent</str>
<str>org.apache.solr.handler.component.HighlightComponent</str>
<str>org.apache.solr.handler.component.DebugComponent</str>
</arr>
</requestHandler>
Perhaps the components should be passed the init params?
Unless there is a compelling reason, I don't think components need to be shared
across request handlers thus justifying a top level component registry.
> Search Components (plugins)
> ---------------------------
>
> Key: SOLR-281
> URL: https://issues.apache.org/jira/browse/SOLR-281
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Attachments: SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch,
> solr-281.patch, solr-281.patch, solr-281.patch
>
>
> A request handler with pluggable search components for things like:
> - standard
> - dismax
> - more-like-this
> - highlighting
> - field collapsing
> For more discussion, see:
> http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#a11050274
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
