In some sense, if all you want to do is send over a URL, e.g. http://localhost:8993/<some stuff>, it's not out of the question to use the java url stuff as exemplified at http://www.cafeaulait.org/course/week12/22.html or http://stackoverflow.com/questions/7500342/using-sockets-to-fetch-a-webpage-with-java
But, that's a trivial case. You might have something else in mind. Jack On Tue, May 14, 2013 at 1:36 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 5/14/2013 3:13 AM, Luis Cappa Banda wrote: >> I know that, but I was wondering if it exists another way just to set the >> complete query (including q, fq, sort, etc.) embedded in a SolrQuery object >> as the same way that you query using some kind of RequestHandler. That way >> would be more flexible because you don't need to parse the complete query >> checking q, fg, sort... parameters one by one and setting them with >> setFields(), setStart(), setRows(), etcetera. Solr is doing that query >> parse internally when you execute queries with it's REST API and maybe >> there exist a way to re-use that functionality to just set a String to a >> SolrQuery and that SolrQuery does internally all the magic. > > This is a little bit of an odd idea, because it goes against the way a > Java programmer expects to do things. Where does the 'URL parameter' > version of your query come from? If it's possible, it would make more > sense to incorporate that code into your SolrJ app and avoid two steps > -- the need to create the URL syntax and the need to decode the URL syntax. > > In a later message, you said that you are working on a SolrServer > implementation to handle your use case. I'm wondering if SolrJ already > has URL query parameter parsing capability. I'd be slightly surprised > to learn that it does - that code is probably part of the servlet API. > > It's not that your idea is bad, it just sounds like a ton of extra work > that could be better spent elsewhere. > > Thanks, > Shawn >