[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538547#comment-13538547
]
Hoss Man commented on SOLR-4143:
--------------------------------
I'm not totally following everything in the comments here, or the motivation
behind everything in the variant patches -- but from what i do understand in
the comments (and from skimming the code) the crux of the problem seems to be...
* SolrQuery.setRequestHandler is confusing
* it's not entirely obvious to people who see SolrQuery.setRequestHandler that
SolrRequest.setPath exists
* In QueryRequest.getPath, if the req params contain a "qt" that starts with a
slash, it is used as both the request path and is left in the params that get
sent to that path.
* QueryRequest.getPath let's the "qt" param trump any explicit path passed to
setPath()
My gut inclination is that we should...
* deprecate SolrQuery.setRequestHandler and advise people to use
QueryRequest.setPath or SolrQuery.setParam(CommonParams.QT,String) -- stop
treating QT as special at the SolrQuery level of hte API
* change QueryRequest.getPath so that if "setPath" has been called (ie: local
var "path" is non null) it trumps the "qt" param. -- update the docs to make
this clear.
Unless i'm missing something, the end result if we do that would be...
* existing code should largely continue to work as before (unless someone was
uselessly calling "QueryRequest.setPath" while also using "qt" with a leading
slash)
** people who specify "qt=foo" will get "/select?qt=foo&..." as they currently
do
** people who specify "qt=/foo" will get "/foo?qt=/foo&..." as they currently do
* people who want to set the path to /foo and have no "qt" param can do the
obvious thing: use setPath("/foo") and never specify a "qt" param
Thoughts?
Optionally, we could decide that moving forward we don't want people to rely on
the client doing anything special if qt starts with a slash, and we can log a
warning in QueryRequest.getPath (if path is null and qt starts with a slash)
that this behavior is deprecated and will be removed in 5.0 and purge it from
trunk.
> setRequestHandler - option to not set qt parameter
> --------------------------------------------------
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 4.0
> Environment: solr-impl 4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
> Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143-alternate.patch, SOLR-4143-alternate.patch,
> SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
