I guess SOLR-599 can be easily fixed if we do not implement
Multipart-support (which is non-essential)
--Noble
On Wed, Apr 15, 2009 at 1:12 AM, Shalin Shekhar Mangar
wrote:
> On Wed, Apr 15, 2009 at 12:47 AM, Glen Newton wrote:
>
>> I see. So this is a show stopper for those wanting to use SolrJ
On Wed, Apr 15, 2009 at 12:47 AM, Glen Newton wrote:
> I see. So this is a show stopper for those wanting to use SolrJ with
> AppEngine.
>
> Any chance this could be added as a Solr issue?
>
>
Yes, commons-httpclient tries to use Socket directly. So it may not work.
It was mentioned here -
http:
I see. So this is a show stopper for those wanting to use SolrJ with AppEngine.
Any chance this could be added as a Solr issue?
-glen
2009/4/14 Smiley, David W. :
> SolrJ would require some modification. SolrJ internally uses Jakarta HTTP
> Client via Solr’s “CommonsHttpSolrServer” class. It w
SolrJ would require some modification. SolrJ internally uses Jakarta HTTP
Client via Solr's "CommonsHttpSolrServer" class. It would need to be ported to
a different implementation of SolrServer (the base class), one that uses
java.net.URL. I suggest "JavaNetUrlHttpSolrServer".
~ David Smiley
I was wondering if those more up on SolrJ internals could take a look
if there were any serious gotchas with the AppEngine's Java urlfetch
with respect to SolrJ.
http://code.google.com/appengine/docs/java/urlfetch/overview.html
"The URL must use the standard ports for HTTP (80) and HTTPS (443).
Th