I notice that SOLR-2724 and SOLR-3161 are in the CHANGES.txt for 3.6.0,
but that they both got reverted on trunk.  Are there plans to put them
back in trunk in a possibly altered form?  I like the general direction
that David Smiley is going, as long as the client API keeps up.

If I follow all the recommendations I've seen in relation to these
issues, I will only have request handlers that start with / and I won't
be using the qt parameter.  This is fine, except that the only way I've
found in SolrJ to specify another handler (such as /edgruberman) is by
using CommonParams.QT ... does this alter the URL path, or just insert a
qt= parameter?  I suspect that it's the latter, which means that there
is a possibility that the request could fail with a potentially
confusing error message, given the requirements in SOLR-3161.

Is there another SolrJ API for specifying a request handler that somehow
has escaped my attention?

Thanks,
Shawn
---------------------------------------------------------------------

On 4/19/2012 2:12 PM, Shawn Heisey wrote:
> I notice that SOLR-2724 and SOLR-3161 are in the CHANGES.txt for
> 3.6.0, but that they both got reverted on trunk.  Are there plans to
> put them back in trunk in a possibly altered form?  I like the general
> direction that David Smiley is going, as long as the client API keeps up.

I thought of another potential problem, something that was at least
touched in the issue comments - distributed search.  The shards.qt
parameter was discussed.  Since the shards parameter doesn't include the
request handler URL path, is shards.qt the only way to specify that?  
One comment suggested that with shards.qt=/something, the shard requests
will change to /something and will not see a qt parameter.  Is that
actually the case in 3.6 or 4.0?

I think that SolrJ (in trunk at least) needs a new set method
(constructor?) to change the URL path, and distributed search needs a
new parameter to replace a deprecated/removed shards.qt.  It might also
need to default to inheriting the request handler path used on the
initial request, assuming that wouldn't cause horrible breakage somewhere.

For me personally, I hope to change my configuration to be as compatible
with 4.0 as possible when I go to 3.6.x, currently on 3.5.0.  It would
be best if we don't have to make any immediate application changes.  If
I absolutely have to use something that's deprecated, I will ... but I'd
rather not.

Thanks,
Shawn
---------------------------------------------------------------------