Hello again! Of course that the part that parses the URL requests must be in Servlet side. However, if the project is well modularized, that Java classes, dependencies... whatever, could be re-used inside SolrJ project, so I don´t think that it would be an enourmous extra work. That´s the magic of Softwre development: reuse as much you can what you´ve done before. And of course is cuestionable if it´s a good or a bad idea, and everyone should have his opinion about it, but I just see advantages and not much extra work for someone that have a good knowledge of Solr main source code project. That´s not my case, :-(
What I´m doing right now is just a wrapper around Solr to implement a custom solution for sharding, both distribute search and indexation operations. I call it SolrCluster, and it´s a black box that from outside is used as a simple Solr Server to execute REST queries or update operations with almost the same syntax, managing Clusters of Solr servers composed by Shards and checking continously each Cluster status. Of course, SolrCloud exists and many people like it, but after using it in test, development and also in one production environments I feel that it doesn´t fit 100% my needs and that it needs some work to become stable. In my SolrCluster implementation queries are execute this way: http://localhost:880/solrcluster/{clusterName}/select?q=*:*&start=0&rows=20&wt=json. .. Now you can understand why I think that it would be extremely useful, powerful and flexible to not necesary bind queries into Java Objects and just play around with String queries. Also, in the future Solr probably should not be a Java Application to be deployed in a Application server, because even these days it has no sense, so enabling a way to execute queries with old fashioned String style from SolrJ would be one task to do in that roadmap. Who knows. The same happens with updates operations, where you POST new data to be indexed: http://localhost:880/solrcluster/{clusterName}/update So that´s why I´m asking for all this stuff, :-) Regards, 2013/5/14 Jack Park <jackp...@topicquests.org> > 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 > > > -- - Luis Cappa
