This is both an FYI for the list so the issue gets documented and a suggestion for the developers. I thought about a JIRA, and would be happy to submit one, but the issue is pretty environment-specific, so I have not done so at this point.
In testing Solr 3.3 under WebSphere Application Server 7 (WAS 7), we discovered that WAS 7 and multiple cores did not get along (at least in cases where security is applied). The result was that any URL request for a core (e.g., /solr/our-core-name/select, /solr/ our-core-name /update and, in particular, /solr/ our-core-name /replication) resulted in 404 errors. Investigation revealed that WAS 7 ignored the filter definition in deciding whether or not a particular resource existed or not. So index pages worked fine (because it knew about them from the WAR) and the default core worked fine (because of the Servlet definitions in web.xml define /select/* and /update/*) but replication did not work at all, even for the default core (because /replication is not defined in web.xml), and select and update requests for other than the default core did not work. To fix it, we added the following for *each* *core* name we had: <servlet-mapping> <servlet-name>SolrServer</servlet-name> <url-pattern>/our-core-name/*</url-pattern> <!-- Note: This mapping is not actually used, but tells the container the resource is not a static web page --> </servlet-mapping> That way WAS 7 knew that the resource existed. Because of the filter, this servlet mapping never actually gets used, so I expect it really does not matter what servlet it points to, but this seemed a likely choice. But putting this in web.xml was enough to tell WAS that the resource existed. It was then able to properly apply security to the resource as well. (Note: We tried <url-pattern>/*</url-pattern> . That works, after a fashion, but because these servlet definitions take priority over static web resources (e.g. /admin/index.jsp), it broke all of that stuff, so we had to go with core by core. 8^) ). (FYI: We then added individual security-constraint entries with associated web-resource-collection entries and auth-constraint entries for /core-name/* [for select and update] and one such entry with multiple URL's to handle security for replication). A suggestion for the developers would be to add some sort of comment in web.xml or at least in the documentation about this need to provide a servlet-mapping entry for each core for WAS 7 (and possibly other web application servers). It took more than a day of research and testing to figure it all out. Jay R. Jaeger State of Wisconsin, Dept. of Transportation
