request for user definable servlet paths

[GoogleCodeExporter]

I see somebody requested this feature a couple years ago which was closed since 
the submitter never responded to your request for a use case:
http://code.google.com/p/solr-php-client/issues/detail?id=18

In my instance we have a use case for this feature (specifically for the ping 
servlet, but it isn't necessary for the other servlets). We recently started 
using a hosted solr service, and the /admin/* URLs aren't available to us but 
they've made the ping servlet available at /ping.

It would work for us if a function was added to Apache_Solr_Service that allows 
the user to override the servlet path, something like:

public function overrideServlet($servlet, $newServlet)
{
    switch($servlet)
    {
        case self::PING_SERVLET:
            $this->_pingUrl = $this->_constructUrl($newServlet);
            break;
        // etc.
    }
}

Alternatively I could envision the Apache_Solr_Service constructor accepting 
another optional argument say as an associative array of servlet mappings that 
it passed to the _initUrls function something like:

protected function _initUrls($customServlets=false)
{
    //Initialize our full servlet URLs now that we have server information
    $this->_extractUrl = $this->_constructUrl((!isset($customServlets[self::EXTRACT_SERVLET])) ? self::EXTRACT_SERVLET : $customServlets[self::EXTRACT_SERVLET]);
    $this->_pingUrl = $this->_constructUrl((!isset($customServlets[self::PING_SERVLET])) ? self::PING_SERVLET : $customServlets[self::PING_SERVLET]);

    // etc...
}

I don't know how likely it is that anybody else needs this feature (or if they 
do, whether they need it for any servlets beyond ping), but if this is a 
feature you'd be willing to add given our use case, and either of my 
suggestions seems reasonable to you I'd be happy to try to whip up a patch with 
an implementation.

Original issue reported on code.google.com by dblue...@gmail.com on 24 Aug 2011 at 12:17

[GoogleCodeExporter]

I think i prefer the overrideServlet way of doing it, between the two, but I 
see arguments for both ways. 

_initUrls is protected so you could also just create your own Service subclass 
that calls the parent method but then constructs it's own _pingUrl after that 
call

...
protected function _initUrls()
{
  // call the parent implementation
  parent::_initUrls();

  // replace the ping url
  $this->_pingUrl = $this->_constructUrl('/ping');
}
...

Original comment by donovan....@gmail.com on 26 Aug 2011 at 3:25

• Changed state: Acknowledged

[GoogleCodeExporter]

Wow, I've been stuck in procedural-programming-land for so long that it didn't 
even occur to me to subclass Service (/facepalm). That'll work fine for our 
needs, particularly if we're the only ones who need this. Thanks for the 
much-needed reminder.

Original comment by dblue...@gmail.com on 29 Aug 2011 at 8:56

[GoogleCodeExporter]

your other suggestions are still very valid, but I think subclassing in this 
case is simplest all around. Glad your problem is resolved.

Original comment by donovan....@gmail.com on 29 Aug 2011 at 9:23

• Changed state: WontFix