Repos Search with Tomcat

[David Gee]

Hi,

Firstly, a disclaimer: I know very little about Tomcat, so if I'm just
being plain ignorant, please do tell me.

I was trying to set up repos-search to run within Tomcat; Jetty is
fine, but if (like me) you're running on Windows, the only way to run
it seems to be in a command prompt window, which isn't ideal. Tomcat
(while perhaps being a little overkill) brings with it the capability
to run as a Windows service. However, I ran into difficulties getting
it to work, although I did eventually figure it out.

If you run a Solr search via Jetty, for example
http://localhost:8090/solr/svnhead/select/?q=horse&qt=content&wt=json,
you get back a sensible response.

If you run the same Solr query via Tomcat (http://localhost:8080/solr/
svnhead/select/?q=horse&qt=content&wt=json), you get back an error:
HTTP Status 404 - /solr/svnhead/select/.

I discovered that if you remove the trailing slash (http://localhost:
8080/solr/svnhead/select?q=horse&qt=content&wt=json), it works in both
Jetty and Tomcat.

Again, this may just be me being ignorant and not configuring Tomcat
correctly, if so please let me know! If it's not just me, would it be
possible to have this corrected (line 70 in index.php from the 1.1.2
tag)?

Regards
David

[solsson]

Hi,

Tomcat should be supported by Repos Search, and the standard
configuration should be fine except that you need to add
URIEncoding="UTF-8" to the connector(s) as recommended in
http://wiki.apache.org/solr/SolrTomcat.

I think the URL with trailing slash is not a valid Solr URL. These
URLs map to handlers in solrconfig.xml in the schema, and those are
all defined without trailing slash. They are REST services rather than
folders so this makes sense. Jetty might not care.

/Staffan

On Sep 17, 10:25 pm, David Gee <da...@allpowerfuldave.com> wrote:
> Hi,
>
> Firstly, a disclaimer: I know very little about Tomcat, so if I'm just
> being plain ignorant, please do tell me.
>
> I was trying to set up repos-search to run within Tomcat; Jetty is
> fine, but if (like me) you're running on Windows, the only way to run
> it seems to be in a command prompt window, which isn't ideal. Tomcat
> (while perhaps being a little overkill) brings with it the capability
> to run as a Windows service. However, I ran into difficulties getting
> it to work, although I did eventually figure it out.
>

> If you run a Solr search via Jetty, for examplehttp://localhost:8090/solr/svnhead/select/?q=horse&qt=content&wt=json,

[David Gee]

Hmm, that's odd.

When I do a search on my test repository for the following URL: http://localhost:8080/solr/svnhead/select?q=shakespeare&qt=meta&start=0&rows=10&wt=json&indent=on

I get a JSON response back:

{
 "responseHeader":{
  "status":0,
  "QTime":3250,
  "params":{
	"indent":"on",
	"start":"0",
	"q":"shakespeare",
	"qt":"meta",
	"wt":"json",
	"rows":"10"}},
 "response":{"numFound":1,"start":0,"docs":[
	{
	 "svnrevision":2,
	 "id":"test^/trunk/New Folder/shakespeare.txt",
	 "content_type":["text/plain"]}]
 }}

But if I do the same search, this time with the slash trailing the select in the URL: http://localhost:8080/solr/svnhead/select/?q=shakespeare&qt=meta&start=0&rows=10&wt=json&indent=on, I get an error 404:

HTTP Status 404 - /solr/svnhead/select/

---

type Status report

message /solr/svnhead/select/

description The requested resource (/solr/svnhead/select/) is not available.

---

Apache Tomcat/7.0.2

Do you think this is something I've misconfigured in Tomcat? I had a look in the svnhead solrconfig.xml that you mentioned, and I saw that the comment at line 415 (this is from v 1.1.2) mentions the select without the trailing slash:

  <!-- 

    Let the dispatch filter handler /select?qt=XXX

    handleSelect=true will use consistent error handling for /select and /update

    handleSelect=false will use solr1.1 style error formatting

    -->

Regards,

David

--
You received this message because you are subscribed to the Google Groups "ReposStyle" group.
To post to this group, send email to repos...@googlegroups.com.
To unsubscribe from this group, send email to reposstyle+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reposstyle?hl=en.

[solsson]

On Sep 20, 4:47 pm, David Gee <da...@allpowerfuldave.com> wrote:
> Hmm, that's odd.
>

> When I do a search on my test repository for the following URL:http://localhost:8080/solr/svnhead/select?q=shakespeare&qt=meta&start...

>
> I get a JSON response back:
>
> {
>  "responseHeader":{
>   "status":0,
>   "QTime":3250,
>   "params":{
>         "indent":"on",
>         "start":"0",
>         "q":"shakespeare",
>         "qt":"meta",
>         "wt":"json",
>         "rows":"10"}},
>  "response":{"numFound":1,"start":0,"docs":[
>         {
>          "svnrevision":2,
>          "id":"test^/trunk/New Folder/shakespeare.txt",
>          "content_type":["text/plain"]}]
>  }}
>

> <http://localhost:8080/solr/svnhead/select?q=shakespeare&qt=meta&start...>But

> if I do the same search, this time with the slash trailing the select in the

> URL:http://localhost:8080/solr/svnhead/select/?q=shakespeare&qt=meta&star...,

> I get an error 404:
>
> HTTP Status 404 - /solr/svnhead/select/

> ------------------------------
>
> *type* Status report
>
> *message* */solr/svnhead/select/*
>
> *description* *The requested resource (/solr/svnhead/select/) is not
> available.*
> ------------------------------

> Apache Tomcat/7.0.2
> Do you think this is something I've misconfigured in Tomcat? I had a look in
> the svnhead solrconfig.xml that you mentioned, and I saw that the comment at
> line 415 (this is from v 1.1.2) mentions the select without the trailing
> slash:
>
>   <!--
>     Let the dispatch filter handler /select?qt=XXX
>     handleSelect=true will use consistent error handling for /select and
> /update
>     handleSelect=false will use solr1.1 style error formatting
>     -->
>
> Regards,
> David
>

My conclusion is: You've configured it correctly. The Solr services
don't have a trailing slash. Jetty might accept those URLs but they
aren't portable between servlet containers.

/Staffan

> > reposstyle+...@googlegroups.com<reposstyle%2Bunsu...@googlegroups.com>
> > .